标签:
在客户公司时,组态、开发、调试都是在计算机A上进行的,运行也是在计算机A上。一切都很正常。当调试完后,就从现场回到杭州,可是后续又出现了一些问题,了解完后就在公司的工作机上进行了实现与编译。之后将修改后的模块发到现场的同事那。当他将完整的系统和新变更的补丁部署到B机后,运行系统,发现报警服务并没有对新产生的报警进行记录。后来远程进行调试后发现,_ConectionPtr指针在调用open时发生了异常,异常信息为“不支持此类借口”。当时第一反应就是MySQL的驱动有没有安装好。在确认完这个完整安装后,重新安装了系统,发现结果还是一样。但是同样的代码,同样的环境,在之前的发行版本中一定是测试过的。而且我自己也在公司的工作机上安装了虚拟机后,拿发行版进行验证,一切都没问题。百思不得其解。后来在检查代码过程中,在同_ConectionPtr指针调用open的同一个cpp中,发现了一行代码:
1 #import "c:\Program Files\Common Files\System\Ado\MSADO15.DLL" no_namespace rename("EOF","EndOfFile")
公司的联编机器的操作系统是win7,而我的工作机是win10。初步怀疑是上面这个dll的问题。在工作机上写了一个demo,在工作机与B机运行的结果不一样,之后将B机的msado15.dll拷贝到工作机进行编译后,发现两方运行的结果一致。
其实这个bug之前就有同事踩到,可是并没有将此问题扩展到产品所有与MySQL相关联的模块进行排查。导致一个坑被踩了两次。根本原因是系统已经更改了COM的IID,导致用老的__uuidof(Connection)会提示E_NOINTERFACE (0X80004002)。
1.将生产环境的msado15.dll拷贝到编译环境下进行编译
2.使用微软提供的Msado60_Backcompat_i386.tlb进行编译,参考此链接
这种写死到某个绝对路径的做法确实值得商榷,尤其是依赖到系统的模块时,情况会更糟。如果必须依赖特定的系统dll,那么最好还是随着产品的代码库一起进行编译。而不是跟随编译环境。
[原]捉虫记3:_ConectionPtr指针调用open失败
标签:
原文地址:http://www.cnblogs.com/navono007/p/5624714.html