Ich habe eine gespeicherte SQL Server-Prozedur, die jedes Mal korrekt ausgeführt wird, wenn sie manuell mit EXEC ausgeführt wird, aber wenn sie als Teil eines SSIS-Pakets ausgeführt wird einen Fehler irgendwie wie folgt aus:Stored Procedure gibt Schemaversionsänderungsfehler bei Ausführung von SSIS zurück, aber nicht bei direkter Ausführung
Executing the query "EXECUTE (ProcName) " failed with the following error:
"The OLE DB provider "SQLNCLI10" for linked server "(OtherServer)" reported a
change in schema version between compile time ("177833127975044") and
run time ("177841717910098") for table (Server.Database.Schema.Table)".
Das Verfahren ist eine MERGE Anweisung, die Daten aus einer Ansicht in eine Tabelle in einer anderen Datenbank auf demselben Server wie der SP übergeht.
Die Ansicht bezieht sich auf den verbundenen Server OtherServer. Die Datenbank, auf die auf dem Verbindungsserver verwiesen wird, wird gelöscht und jede Nacht neu erstellt.
Bisher habe ich diese Dinge versucht:
1) Dropping und neu zu erstellen, die Ansicht vor der MERGE ausgeführt wird.
2) Definieren des SP, der die MERGE WITH RECOMPILE enthält.
3) Verpackung der MERGE-Anweisung in EXEC(), so dass es nicht im Voraus kompiliert werden würde.
4) Einstellung von Bypass Prepare im SSIS auf den relevanten Schritt auf true setzen.
bearbeiten:
Der Server mit der gespeicherten Prozedur ist SQL Server 2008 ausgeführt Der Verbindungsserver ist 2008 R2.
Ein bisschen schwerfällig, aber können Sie Daten (nicht mit SSIS) aus der neu erstellten Datenbank in eine statische Datenbank jedes Mal neu erstellen, wenn es neu erstellt wird, und beziehen Sie sich auf die statische Datenbank in der Ansicht. Ich bin mir nicht sicher, ob es eine Möglichkeit gibt, SSIS dazu zu bringen, mit einer Datenbank, die gelöscht und neu erstellt wird, nett zu spielen. Es sei denn, Sie erstellen Ihr SSIS-Paket auch jedes Mal neu. –
Welche Version von SSIS verwenden Sie? –
Es gibt einige verwandte Diskussion [hier] (http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/0223b695-f698-41a6-8ddc-deabd6306aae/). – criticalfix