Réponse.

Le besoin de fixer les lignes erronées lors de l'importation massive est apparu presque immédiatement après l'avènement des chargements automatiques de grandes quantités de données dans les bases. Traditionnellement, toute violation des contraintes (par exemple, des violations de types de données, des contraintes) entraînait l'interruption de l'ensemble du processus d'importation même pour une seule ligne erronée - ce qui entraînait la perte des enregistrements corrects comme incorrects.

Le problème réside dans le fait de non seulement charger le maximum de données correctes, mais aussi de conserver un audit et une description détaillée des erreurs pour un travail manuel ultérieur, plutôt que de simplement "annuler tout".

Solution : Pour certains SGBD (par exemple, PostgreSQL, SQL Server avec SSIS, Oracle avec des utilitaires EXTERNAL TABLES), il existe des mécanismes de téléchargement avec séparation des lignes erronées. Pour une méthode universelle - utiliser des tables de staging et une validation post-upload via OUTER JOIN et NOT EXISTS, ainsi que des "tables de log" associées, où les lignes problématiques sont manuellement enregistrées.

Exemple de code :

-- 1. Charger tout dans une table de staging temporaire
BULK INSERT staging_payments FROM 'payments.csv' WITH (...)

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

-- 3. Logger les lignes erronées dans une table séparée
INSERT INTO import_errors (row_data, error_desc)
SELECT *, 'Statut incorrect ou somme négative'
FROM staging_payments
WHERE amount <= 0 OR status NOT IN ('approved', 'pending');

Caractéristiques clés :

Permet de ne pas perdre d'informations sur les lignes problématiques (loggées dans une table séparée).
Permet de charger rapidement des données "propres" en masse et de traiter les erreurs séparément.
Il est possible d'étendre la typologie des erreurs et de conserver des informations supplémentaires.

Questions pièges.

Est-il possible de tout réaliser via ON ERROR RESUME NEXT dans SQL ?

La norme SQL ne contient pas de telle construction pour l'importation massive par opérateur. Dans la plupart des cas, le rapport d'erreurs est généré dans des outils externes ou dans des tables de log, comme décrit ci-dessus.

Est-il possible d'utiliser une transaction pour annuler uniquement les lignes erronées ?

Lors d'un rollback de transaction, toutes les lignes sont annulées d'un coup (atomicité). Une conservation partielle est possible uniquement en chargeant d'abord dans une table de staging, après quoi un commit manuel des lignes réussies et un log des lignes non réussies sont effectués.

Pourquoi est-il inefficace d'attraper chaque erreur INSERT via TRY/CATCH dans une boucle pour chaque ligne ?

Le traitement séquentiel de millions de lignes via des INSERT simples + TRY/CATCH entraîne une chute catastrophique des performances par rapport à un traitement par lots ou BULK INSERT + vérification après le chargement.

Erreurs typiques et anti-patterns

Essayer de charger des données en masse sans vérification préalable ou table de staging mène à un rollback de l'ensemble du chargement en cas d'une seule erreur.
Lancer de multiples INSERT simples dans une boucle avec capture des erreurs - ralentit considérablement le chargement, a un impact négatif sur les blocages.
Enregistrer des erreurs uniquement dans un fichier externe, et non dans une table, complique l'audit et l'automatisation des corrections.

Exemple de la vie réelle

Cas négatif

Une entreprise a chargé des dizaines de milliers de lignes via un script INSERT, et en cas d'erreur sur une clé unique, l'ensemble du lot était annulé. Cela a entraîné des temps d'arrêt et une perte de données.

Avantages:

Sécurité (aucune donnée incorrecte). Inconvénients:
Perte de temps, impossibilité de sauvegarde partielle, correction manuelle de l'ensemble du fichier.

Cas positif

L'utilisation d'une table de staging, de la journalisation des erreurs et de la séparation des données entrantes en catégories "valides/invalides" a permis d'accélérer l'importation, de conserver et d'analyser automatiquement les refus.