Question

Nous utilisons la grille InQuest DLL Quest Geo Solution (GIQ60.DLL) dans un package SQL Server Integration Services (SSIS). Nous avons réussi à utiliser sans problème localement (32bit) en utilisant tlbimp pour créer un wrapper .NET (PIA). Cependant, lorsque cela déplacé à notre serveur d'intégration cela ne fonctionne pas comme le serveur est 64bit.

Le GIQ60.DLL est une DLL 16 bits et le vendeur a confirmé qu'ils ne supportent plus activement cela. Si nous courons la version 32 bits de DTExec sur le serveur, le package fonctionne sans problèmes. Y at-il une astuce / moyen de convertir l'emballage .NET pour permettre que cela fonctionne SQL Server Integration Services (64bit installation).

Sinon, nous avons besoin d'un 32bit sans remplacement bibliothèque .net qui convertira la grille OS (Abscisse / Ordonnées) en longitude géospatiale / latitude pour les deux au Royaume-Uni et de l'Irlande (ils utilisent des systèmes de réseaux différents), alors ce serait une solution viable.

Était-ce utile?

La solution

La seule autre solution que je peux penser est de créer un service Windows (32 bits) qui héberge votre composant et il expose comme WCF ou Remoting point final. Utilisez ensuite la tâche de script dans SSIS pour y accéder. De cette façon, vous pouvez exécuter votre package dans 64bit DTExec et votre composant dans le processus de 32bit.

HTH

Autres conseils

Dans un environnement que je soutiens, il y a un package SSIS qui repose sur une certaine version d'une connexion à Lotus Notes. Ce dll est une dll 32 bits et il ne fonctionne pas lors de l'exécution dans SSIS sur le serveur de production 64Bit.

Nous exécutons simplement le package SSIS avec un appel invite de commande à la version 32 bits de DTExec. Cela fonctionne très bien.

Vous pouvez essayer d'éviter d'avoir à maintenir deux versions différentes de code?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top