在 64 位计算机上使用 Quest Geo Solutions GIQ60 库
我们在 SQL Server Integration Services (SSIS) 包中使用 Quest Geo Solution 的 Grid InQuest DLL (GIQ60.DLL)。通过使用 tlbimp 创建 .NET 包装器（互操作），我们已经成功地在本地（32 位）使用它，没有出现任何问题。然而，当它转移到我们的集成服务器时，它就不起作用了，因为服务器是 64 位的。
GIQ60.DLL 是一个 16 位 DLL，供应商已确认他们不再主动支持这一点。如果我们在服务器上运行 32 位版本的 DTEXEC，则该包运行不会出现问题。有没有一种技巧/方法可以转换 .NET 包装器，使其能够运行 SQL Server Integration Services（64 位安装）。
或者，我们需要一个免费的 32 位 .net 库来替换，它将操作系统网格（东向/北向）转换为英国和爱尔兰的地理空间经度/纬度（他们使用不同的网格系统），那么这将是一个可行的解决方案。
We are using Quest Geo Solution's Grid InQuest DLL (GIQ60.DLL) within an SQL Server Integration Services (SSIS) package. We have managed to use this without problems locally (32bit) by using tlbimp to create a .NET wrapper (interop). However, when this moved to our integration server this does not work as the server is 64bit.
The GIQ60.DLL is a 16bit DLL and the vendor has confirmed that they no longer actively support this. If we run the 32bit version of DTEXEC on the server , the package runs without problems. Is there a trick/way to convert the .NET wrapper to enable this to work SQL Server Integration Services (64bit install).
Alternatively , we need a replacement free 32bit .net library that will convert OS grid (Easting /Northings) into geospatial longitude/latitude for both UK and Ireland (they use different grid systems) then that would be a viable solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我能想到的唯一其他解决方案是创建一个 Windows 服务（32 位）来托管您的组件并将其公开为 WCF 或远程处理端点。然后使用SSIS中的脚本任务来访问它。这样您就可以在 64 位 DTEXEC 中运行您的包，并在 32 位进程中运行您的组件。
华泰
The only other solution i can think of is to create a windows service (32bit) that hosts your component and exposes it as WCF or Remoting end point. Then use script task in SSIS to access it. This way you can run your package in 64bit DTEXEC and your component in 32bit process.
HTH
在我支持的一个环境中，有一个 SSIS 包依赖于特定版本的 Lotus Notes 连接。该 dll 是 32 位 dll，在 64 位生产服务器上的 SSIS 中执行时它不起作用。
我们通过命令提示符调用 32 位版本的 DTEXEC 来简单地执行 SSIS 包。效果很好。
您可能会尝试这样做以避免维护两个不同版本的代码？
In one environment I support, there is an SSIS package that relies on a certain version of a connection to Lotus Notes. That dll is a 32 bit dll and it doesn't work when executing in SSIS on the 64Bit production server.
We simple execute the SSIS package with a command prompt call to the 32Bit version of DTEXEC. That works fine.
You might try that to avoid having to maintain two different versions of code?