Il arrive de temps en temps que,
sous BIDS, nous redirigions la sortie d’erreur de nos composants (et donc les
lignes du flux) vers un composant « poubelle » : ce fameux colonne dérivée qui ne sert à rien. Ce
qu’il faut savoir, c’est qu’une fois notre lot lancé avec DTEXEC, donc en
dehors du mode debug, le processus va chercher à optimiser le lot en supprimant
du Data Flow les composants qui ne servent à rien, donc notre Derived Column « poubelle ».
Dit comme cela, rien de bien méchant. Sauf quand votre Data Flow utilise un
composant Script qui lit un fichier plat en tant que source et que le message
d’erreur est le suivant :
Du coup, on pense à un souci avec
le stream de notre Script, puis à un problème de synchronisation des entrées et
des sorties, puis que SSIS a un bug, on « google-ise » sur
System.Runtime.InteropServices.COMException, sur le HResult 0xC0047020, etc. En
fait, c’est juste que DTEXEC ne sait pas quoi faire des lignes redirigées vers
la sortie d’erreur.
Moralité : attention à la signification réelle des messages d’erreur SSIS (mais ça on le savait déjà) et pensons à gérer
correctement les lignes que notre flux ne peut pas assimiler. Plusieurs raisons
à cela. A la vue de cet exemple, ça peut poser des soucis à l’exécution.
Ensuite, cette information mal formatée peut être utile à votre client et doit
lui être remontée d’une façon ou d’une autre (une table de log par exemple).
