Ich arbeite an einem großen ETL- und DW-Projekt, bei dem wir TFS / Quellcodeverwaltung zusammen mit SSIS und SSDT verwenden.
Heute habe ich herausgefunden, dass während ein SSIS-Paket ein BULK INSERT in eine Datenbanktabelle ausführt, es nicht möglich ist, einen SSDT-Schema-Vergleich mit dieser Datenbank durchzuführen. Dies ist bedauerlich, da einige unserer Pakete ziemlich lange dauern. Wir möchten die Schema-Vergleichsfunktion verwenden, um Änderungen an der Datenbankstruktur zu erkennen und diese in unserem SSDT-Projekt zur Versionskontrolle der Datenbank zu speichern.
Bei näherer Betrachtung stellte ich fest, dass die Schema Compare-Funktion in SSDT ein SQL-Skript ausführt, das die OBJECTPROPERTY()Systemfunktion für die Tabellen in der Datenbank aufruft . Insbesondere in meinem Fall OBJECTPROPERTY(<object_id>, N'IsEncrypted')scheinen alle Aufrufe von blockiert zu sein, wenn <object_id>auf eine Tabelle verwiesen wird, die gerade als Masseneinfügung ausgeführt wird.
In Visual Studio tritt beim SSDT-Schema-Vergleich nach einer Weile einfach eine Zeitüberschreitung auf und es wird behauptet, dass keine Unterschiede festgestellt wurden.
Gibt es eine Problemumgehung für dieses Problem in SSDT oder sollte ich möglicherweise versuchen, einen MS Connect-Fehlerbericht einzureichen?
Gibt es alternativ, da das BULK INSERT aus einem SSIS-Paket stammt, möglicherweise eine Möglichkeit, diese Einfügung vorzunehmen, ohne OBJECTPROPERTY-calls auf dem Tisch zu sperren ? Bearbeiten: In SSIS OLE DB-Zielen können wir das Häkchen aus "Tabelle sperren" entfernen, das genau das tut, was es sagt. Dies kann jedoch in einigen Situationen die Leistung beeinträchtigen. Ich bin viel mehr an einer Lösung interessiert, mit der der SSDT-Schema-Vergleich seine Aufgabe erfüllen kann, selbst wenn einige Objekte gesperrt sind.
