Change control / Cupcake field notes
MySQL data comparison: review drift before repair
A comparison becomes useful when you can turn its findings into a specific, reviewable decision about the target.
Start with the comparison’s scope.
A difference is meaningful only in context. Confirm which source and target were compared, the tables and mappings used, and when the comparison ran. Check whether results cover the whole intended scope or only the subset selected for this run.
In Cupcake-DRCP for macOS, row review lets you inspect missing, extra, and differing data. A missing row suggests an insert, a changed row may need an update, and an extra target row requires a separate decision about deletion.
Preview what would change.
Before applying, review the destination and the proposed counts. Narrow the tables to the work you intend to authorize. Exclude individual rows when they should remain untouched, and make the delete decision deliberately.
This is the value of a dry-run review: it makes the change visible before it becomes a write. It is still a review of a particular comparison. If the source or target has moved on, run a fresh comparison and reassess the plan instead of relying on a stale result.
Apply now, or hand over a SQL script.
The Mac app offers two ways forward: apply the selected changes to the target, or save a reconciliation script. Interactive apply uses explicit confirmation and Touch ID or the Mac password. Scheduled repair follows the policy authorized when it is configured.
Saving a SQL script does not execute it. It gives a DBA or reviewer a concrete artifact to inspect and run during an appropriate change window. The statements can still change or delete data when executed, so the review needs to include the target, table scope, and any included deletes or SQL hooks.
Share findings in the right format.
Export a readable HTML comparison report for a ticket, an Excel workbook for a colleague, or JSON for another tool. CSV and TSV are also available. Choose a summary or include the row differences retained by the comparison.
Be deliberate about who receives row-level exports: the file may contain database values. Desktop history and exported results are useful operational evidence, but they do not establish an immutable audit log, access policy, or compliance certification by themselves.
Verify after the work completes.
Review the reconciliation’s actual outcome and investigate failures before calling the target aligned. Run a follow-up comparison for the same scope. Keep the relevant result with the change record so another person can see what was checked and what happened.
For recurring work, schedule comparisons and authorize automatic repair only within a limit appropriate to the environment. A row ceiling gives larger changes a reason to stop for review instead of making every difference an automatic write.