Antwoord.

De behoefte om foutieve rijen vast te leggen bij massale gegevensimport ontstond vrijwel meteen na de komst van automatische uploads van grote hoeveelheden gegevens in databases. Traditioneel leidde elke schending van beperkingen (bijvoorbeeld datatypes, constraints) tot een onderbreking van het gehele importproces, zelfs omwille van één foutieve rij — met als gevolg dat zowel correcte als onjuiste records verloren gingen.

Het probleem is niet alleen om zoveel mogelijk correcte gegevens te laden, maar ook om audits en gedetailleerde foutomschrijving achter te laten voor verdere handmatige verwerking, in plaats van gewoon alles "terug te draaien".

Oplossing: Voor sommige databases (bijvoorbeeld PostgreSQL, SQL Server met SSIS, Oracle met EXTERNAL TABLES-tools) zijn er mechanismen voor het laden met gescheiden slechte rijen. Voor een universele aanpak — gebruik staging-tabellen en post-upload validatie via OUTER JOIN en NOT EXISTS, evenals gekoppelde "log-tabellen" waar probleemrijen handmatig worden geschreven.

Voorbeeldcode:

-- 1. Laad alles in een tijdelijke staging-tabel
BULK INSERT staging_payments FROM 'payments.csv' WITH (...)

-- 2. Filter correcte rijen
INSERT INTO payments (id, amount, ...)
SELECT id, amount, ... FROM staging_payments
WHERE amount > 0 AND status IN ('approved', 'pending');

-- 3. Log foutieve rijen in een aparte tabel
INSERT INTO import_errors (row_data, error_desc)
SELECT *, 'Ongeldige status of negatieve som'
FROM staging_payments
WHERE amount <= 0 OR status NOT IN ('approved', 'pending');

Belangrijke kenmerken:

Laat geen informatie over probleemrijen verloren gaan (gelogd in een aparte tabel).
Maakt het mogelijk om "schone" gegevens snel massaal te laden, terwijl fouten apart worden verwerkt.
Er kan extra informatie over fouten worden opgeslagen en de type-mapping kan worden uitgebreid.

Vragen met een valstrik.

Kan alles worden uitgevoerd via ON ERROR RESUME NEXT binnen SQL?

De SQL-standaard bevat dergelijke constructies voor massale operationele import niet. In de meeste gevallen wordt de foutmelding gegenereerd in externe hulpmiddelen of in log-tabellen, zoals hierboven beschreven.

Kan een transactie worden gebruikt om alleen foutieve rijen terug te draaien?

Bij het terugdraaien van een transactie worden alle rijen in één keer teruggedraaid (atomiciteit). Deeltijdbewaring is alleen mogelijk door eerst in een staging-tabel te laden, waarna handmatig een commit wordt uitgevoerd voor succesvolle rijen en niet-succesvolle rijen worden gelogd.

Waarom is het niet effectief om elke INSERT-fout via TRY/CATCH in een loop voor elke rij te vangen?

Sequentiële verwerking van miljoenen rijen via enkele INSERT + TRY/CATCH leidt tot een catastrofale daling van de prestaties in vergelijking met batch of BULK INSERT + validatie na het laden.

Typische fouten en anti-patronen

Pogingen om massale ladingen van gegevens te importeren zonder voorafgaande controle of staging-tafel leidt tot terugrol van de hele lading wanneer er ook maar één fout optreedt.
Het uitvoeren van meerdere afzonderlijke INSERT binnen een loop met foutopsporing vertraagt de lading aanzienlijk en heeft een negatieve invloed op locks.
Alleen het registreren van fouten in een extern bestand, in plaats van in een tabel, complicert auditing en automatisering van correcties.

Voorbeeld uit het leven

Negatieve case

Een bedrijf laadde tienduizenden rijen via een INSERT-script, en bij een fout door een unieke sleutel werd de hele batch teruggedraaid. Dit veroorzaakte downtime en gegevensverlies.

Voordelen:

Veiligheid (geen ongeldige gegevens). Nadelen:
Tijdverlies, geen mogelijkheid voor gedeeltelijke bewaring, handmatige correctie van het hele bestand.

Positieve case

Het gebruik van een staging tabel, foutlogging en het scheiden van binnenkomende gegevens in "valide/ongeldige" categorieën stelde ons in staat om de import te versnellen, en om afwijzingen op te slaan en automatisch te analyseren.