A parameterized date supplies the processing date as an input instead of embedding a changing expression in ETL code. Hardcoding WHERE DataDate = GETDATE() may seem convenient, but a run scheduled at 10 p.m. cannot be rerun reliably for its intended date without code changes. section 12.5
Mistake: using the clock as the processing date
An ETL process fails partway through, then is manually restarted. A GETDATE()-based filter now selects a different time window, while repeated INSERT statements can create duplicate business keys across multiple transactions. Pass the intended processing date explicitly, then merge the resulting data. section 12.5
Use parameterized dates with these safeguards:
- Keep original source data available through retention, configurable APIs, or caching. section 12.5
- Merge into target tables rather than relying only on INSERT statements. section 12.5
