Pregunta

Estamos utilizando la rejilla investigación DLL búsqueda de soluciones de Geo (GIQ60.DLL) dentro de un paquete de SQL Server Integration Services (SSIS). Hemos logrado utilizar esto sin problemas a nivel local (32 bits) mediante el uso de tlbimp para crear un envoltorio NET (interoperabilidad). Sin embargo, cuando este se trasladó a nuestro servidor de integración esto no funciona como el servidor es de 64 bits.

El GIQ60.DLL es una DLL de 16 bits y el vendedor ha confirmado que ya no apoyan activamente este. Si se corre la versión de 32 bits de DTEXEC en el servidor, el paquete se ejecuta sin problemas. ¿Hay un truco / manera de convertir la envoltura .NET para permitir que esto funcione SQL Server Integration Services (64bit instalar).

Como alternativa, necesitamos una biblioteca .NET de 32 bits libre de reemplazo que convertirá rejilla del OS (Coordenada X / Norte) en geoespacial longitud / latitud, tanto para el Reino Unido e Irlanda (que utilizan diferentes sistemas de red), entonces eso sería una solución viable.

¿Fue útil?

Solución

La única otra solución que se me ocurre es crear un servicio de Windows (32 bits) que aloja el componente y lo expone como WCF o de interacción remota punto final. A continuación, utilice la tarea de la escritura en SSIS para acceder a ella. De esta manera usted puede ejecutar su paquete en DTEXEC de 64 bits y su componente en el proceso de 32 bits.

HTH

Otros consejos

En un entorno de apoyo, hay un paquete SSIS que se basa en una determinada versión de una conexión con Lotus Notes. Esa DLL es una DLL de 32 bits y no funciona cuando se ejecuta en SSIS en el servidor de producción de 64 bits.

sencilla ejecutar el paquete de SSIS con una línea de comandos llamada a la versión de 32 bits de DTEXEC. Eso funciona bien.

Usted puede tratar de que para evitar tener que mantener dos versiones diferentes del código?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top