Sales Lot Backfill

Repairs the FK columns on sales_lot: runner_id (→ runner, from tbltsales_lots.SL_HorseId), sale_id and session_id. This value can end up wrong in two distinct ways: never resolved at migration time (left NULL), or correct at migration time but the source horse's mapping later moved on (a stale, still-valid-looking runner id) with nothing re-syncing it. A single rule fixes both: for every already-migrated sales_lot row, this re-reads its current source SL_HorseId, translates each through the current config_id_mappings, and corrects the column if it disagrees.

Only already-resolvable rows are touched — a sales lot whose horse genuinely hasn't migrated yet is left alone and counted as skipped, never auto-copied. Unlike Race Meeting Backfill, this feature has no date-floor/cutoff: sales_lot has no race_date-equivalent column to scope by (its only date-like field, foal_date, is the horse's birth date and unrelated), so every run is a full, unbounded sweep. This is a targeted FK-only pass, unrelated to and safe alongside Auto Sync and other backfills: it only ever reads/updates sales_lot rows that already have a durable config_id_mappings entry, which Auto Sync never touches mid-insert.

  • Sales Lot → Runner FK tbltsales_lots.SL_HorseId → sales_lot.runner_id
  • Sales Lot → Sale FK tbltsales_lots.saleId → sales_lot.sale_id
  • Sales Lot → Session FK tbltsales_lots.sessionId → sales_lot.session_id

Preview runs the exact same reads and resolves the exact same expected values, but skips the actual write — no runner_id is changed. Use it to see what would change before committing to a real run.

Scheduled Backfill

Runs this same re-resolution pass automatically on a recurring interval instead of only ever running it by hand.

1440 = daily · 10080 = weekly