Frage

Wir sind mit Quest-Geo-Lösung von Grid InQuest DLL (GIQ60.DLL) innerhalb eines SQL Server Integration Services (SSIS) Paket. Wir haben es geschafft, diese lokal ohne Probleme zu benutzen (32bit) unter Verwendung von tlbimp zu einer .NET-Wrapper (Interop) zu erstellen. Wenn dies jedoch zu unserer Integration Server verschoben dies nicht funktioniert, wie der Server 64-Bit ist.

Die GIQ60.DLL ist ein 16-Bit-DLL und der Verkäufer hat bestätigt, dass sie nicht mehr aktiv dabei unterstützen. Wenn wir die 32-Bit-Version von DTEXEC auf dem Server ausführen, wird das Paket ohne Probleme. Gibt es einen Trick / Weg, um den .NET-Wrapper zu konvertieren, dies zu ermöglichen, SQL Server Integration Services zu arbeiten (64bit installieren).

Alternativ brauchen wir einen Ersatz kostenlos 32bit .net-Bibliothek, die dann für die OS-Gitter (Easting / Koordinaten X) in geospatial Länge / Breite sowohl in Großbritannien und Irland (sie verwenden unterschiedliche Grid-Systeme) konvertieren, dass wäre eine gangbare Lösung sein.

War es hilfreich?

Lösung

Die einzige andere Lösung, die ich denken kann, ist ein Windows-Dienst (32bit) zu erstellen, die Ihre Komponente hostet und setzt sie als WCF oder Endpunkt Remoting. Dann Skript-Task in SSIS verwenden, um darauf zuzugreifen. Auf diese Weise können Sie Ihr Paket in 64-Bit-DTEXEC und Ihre Komponente in 32-Bit-Prozess ausgeführt werden.

HTH

Andere Tipps

In einer Umgebung, die ich unterstützen, gibt es ein SSIS-Paket, das auf eine bestimmte Version einer Verbindung zu Lotus Notes beruht. Das DLL ist ein 32-Bit-DLL und es funktioniert nicht, wenn in SSIS auf dem 64Bit Produktionsserver ausgeführt wird.

Wir einfach das SSIS-Paket mit einer Eingabeaufforderung Aufruf der 32Bit-Version von DTEXEC auszuführen. Das funktioniert gut.

Sie könnten versuchen, dass zu vermeiden, zwei verschiedene Versionen von Code zu pflegen?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top