Die OLE DB Command Task bietet die Möglichkeit innerhalb eines Dataflows Änderungen an der Datenbank per Update, Insert oder Delete vorzunehmen. Auch sehr praktisch ist die Verwendung als Target um z.B. Änderungen nicht direkt auf der Datenbank zu machen, sondern per StoredProcedure zu kapseln. StoredProcedures erwarten ihre Paramater entweder in der exakten Reihenfolge, in der sie definiert sind, oder per Named-Parameter, wobei hier die Reihenfolge irrelevant ist. Beide Varianten können auch in der OLE DB Command Task verwendet werden, wobei die Named-Parameter Version Vorteile bietet, aber mit Vorsicht zu genießen ist, wie die folgende Beschreibung schildert. In der Regel geht man so vor, dass man sich den Aufruf der StoredProcedure per SSmS (MS SQLServer Management Studio) oder anderen Tools erstellen lässt., da dort gleich die Parameter per Named-Parameter angegeben und somit leichter zuordenbar sind. Diese Abfrage fügt man dann so der OLE-DB Command Task als Statement hinzu, führt das Mapping durch, evoila, das war's. Diese Vorgehensweise hat den Vorteil, dass das Mapping zwischen Eingabespalten und Parametern sehr einfach wird, da die Named - Parameter auch so im OLE-DB_Command Container angezeigt werden. Im Designer wird alles richtig angezeigt, die Hints bei Parametern und Spalten zeigen auch die richtige Feldtypen, also alles scheinbar kein Problem. Jedoch wird intern nicht mit Named-Parameter gearbeitet, sondern rein mit der Reihenfolge. Sollte sich also irgendwas an den Parametern der StoredProcedure ändern (Anzahl, Reihenfolge, etc), dann muss das entsprechend im Designer abgeändert werden, oder man lässt sich am besten den Aufruf erneut generieren und macht das Mapping neu, damit entgeht man allen Fallstricken. Im aktuellen Fall war das Problem nun, das ein Parameter "@PersonID" als UniqueIdentifier hinzukam und dieser Parameter manuell zum SqlCommand der Task hinzugefügt wurde. Aber statt hinter dem Parameter "@PersonalNumber" wurde er versehentlich davor eingefügt. Beim Mapping zeigt der Designer keine Fehler an, auch die Feldtypen stimmen überein, nur beim Ausführen weißt er dann den Wert von "PersonID" an die Postion "@PersonalNumber" zu, was zu einem Type clash (cannot assign Bigint to UniqueIdentifier) führte. Und dummerweise gibt die weitergeleitete Fehlermeldung per ErrorOutput und ReditectRows im Errorhandler nur den allgemeinsten Fehler weiter (The data value cannot be converted for reasons other than sign mismatch or data overflow.). Lässt man den Errorhandler weg, dann zeigt der Designer wenigstens den Operand Clash an, was letztendlich auch zur Fehlerbehebung führte.