Every time a report of "the data does not match" comes in, the first temptation is to open the code. Yet the cheaper question can usually be answered first, in the database: is the data actually wrong, or is the way we are reading it wrong?

Three questions I always ask

How many rows are involved? If the complaint is about one item but the same condition holds across thousands of rows, then it is not a special case.

When did it last change? A timestamp column often points straight at the event. Changes that cluster inside one particular hour almost always share a trigger.

Is the data shaped the way I assume? Free-text columns are the most common source of trouble. The same name typed with different spacing is enough to make two rows count as two different things.

A staging copy has saved me more than once

When something needs to be repaired, I never write changes straight into live data. I compare it first against the previous day's staging copy, find the difference, and only then decide what to do.

Two minutes reading a difference is far cheaper than an hour undoing the effects of a statement that has already run.

A small habit that helps

I keep the queries I use often in a single file, each with a short note about when it is useful. Nothing elaborate: finding duplicates, checking which rows changed today, comparing counts per category.

It is not clever. But when somebody asks a question during a busy hour, I do not have to rebuild the SQL from scratch, and the answer rests on numbers rather than a guess.