Domanda

Stiamo utilizzando Quest Geo Solution griglia InQuest DLL (GIQ60.DLL) all'interno di un pacchetto di SQL Server Integration Services (SSIS). Siamo riusciti a utilizzare questo senza problemi a livello locale (32 bit) utilizzando tlbimp per creare un wrapper .NET (interoperabilità). Tuttavia, quando questo si trasferì al nostro server di integrazione non funziona come server è a 64 bit.

Il GIQ60.DLL è una DLL a 16 bit e il venditore ha confermato che supportano più attivamente questo. Se si corre la versione a 32 bit di DTEXEC sul server, il pacchetto viene eseguito senza problemi. C'è un trucco / modo per convertire il wrapper .NET per permettere questo al lavoro SQL Server Integration Services (64bit installazione).

In alternativa, abbiamo bisogno libera una libreria .NET a 32 bit di sostituzione che converte griglia OS (Est / Northings) in geospaziale longitudine / latitudine sia per Regno Unito e Irlanda (che utilizzano diversi sistemi di rete) allora che sarebbe una soluzione praticabile.

È stato utile?

Soluzione

L'unica altra soluzione che posso pensare è quello di creare un servizio di Windows (32 bit) che ospita il componente e lo espone come WCF o Remoting punto finale. Quindi utilizzare un'attività di script in SSIS per accedervi. In questo modo è possibile eseguire il vostro pacchetto in 64 bit DTEXEC e il componente nel processo a 32 bit.

HTH

Altri suggerimenti

In un ambiente sostengo, c'è un pacchetto SSIS che si basa su una certa versione di un collegamento a Lotus Notes. Questo dll è un 32 bit dll e non funziona quando si esegue in SSIS sul server di produzione a 64 bit.

semplice eseguire il pacchetto SSIS con una chiamata prompt dei comandi per la versione a 32 bit di DTEXEC. Che funziona bene.

Si potrebbe provare che, per evitare di dover mantenere due diverse versioni di codice?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top