公司本身的系统为BS架构,用SQL2005和VS2003开发。公司也根据网络版开发了相应的单机版软件,使用Access数据库。客户方希望能在网络版上做的工程导出到单机版使用,单机版做完后再导入到网络版。于是便产生了导入导出的任务。
导入导出的代码我们决定在BS架构上完成,于是便产生了下面的程序代码:
Dim AccessDrive As String = "openDataSource('Provider=Microsoft.Jet.OLEDB.4.0','Data Source=" & _"" & DPath & "" & _";Jet OLEDB:Database Password=" & pwd & ";)..."SqlString = "insert into " & AccessDrive & "TblGC_GYS_BD_GCGK " & _"(BQRL,GHRL,T1)" & _"select BQRL,GHRL,T1 from TblGC_GYS_BD_GCGK where GCXH=" & gcxhIf AoToTbl(SqlString, Myconn) = -1 Thenlog.WriteLogToDB(SqlString) : GCout = -1Exit FunctionEnd If
我们的方法是在SQL2005里调用含有OpenDataSource函数的SQL语句,直接将Select来的数据Insert到Access数据库中,这样做我们的工作量较少,而且在性能上也能接受,所以所有的导入导出都使用了这种技术。
但是,最近恶梦随之而来,其中一个客户方由原来的32位Windows 2003升级到64位,而且SQL2005也是。客户方说系统的导入导出操作无法完成。于是我们立即检查,在网上一搜索,发现64位系统不支持 Microsoft.Jet.OLEDB.4.0 这个访问Access的驱动,于是搜遍了网络,逐一按照网上的方法,都不行。
1:安装Office 2007 ,使用 Microsoft.ACE.12.0驱动,不行,OpenDatasource依然报错。
2:安装网上的指示,下载最新的MDAC驱动安装,不行
3:安装最新的Jet 4.0 for windows 2003 64位补丁,发现只支持英文版系统。
4:安装微软最新的AccessDataCompenent组件,不行。
5:在ODBC的驱动管理器里找不到这个Jet
6:尝试使用可以代替OpenDataSource的OpenQuery或OpenRowSet函数,发现始终逃离不了OLEDB驱动的问题。
但是我们发现,原有系统的导出Excel功能能正常使用,但是导出Excel功能也是使用Microsoft.Jet.OLEDB.4.0驱动的啊,于是我尝试在程序里直接使用这个驱动访问Access文件:
Dim AccessDB As New OleDbConnectionAccessDB.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:/Test.mdb;Jet OLEDB:Database Password=;"AccessDB.Open()
发现竟然没有报错,而且可以使用这个链接来访问Access数据。最后才发现,原来这个64位的03系统是R2 SP2 版本的。已经有了 Jet 4.0 的访问驱动。但是我们一开始的代码还是无法执行。最后得出结论:整个SQL语句是提交给SQL2005执行的,而其中的OpenDataSource函数不能使用Microsoft.Jet.OLEDB.4.0,就算是Microsoft.ACE.12.0也不行。一样提示此访问接口未注册。这次充分体验到技术依赖的恶果了···
我们最后的解决方案有两个:
1:在客户机的64位系统上安装一个虚拟机,然后在虚拟机里安装Windows 2003 32位和SQL2005 32位。把整个程序放到虚拟机的环境里运行。这个解决方法在公司的环境里是完全可行的。可是客户方的环境不同,一来客户系统里不单单运行我们公司的系统,还运行着其他系统,而且因为虚拟机会虚拟一个网卡出来,而虚拟系统的IP地址就得静态分配了。但是这个IP地址的分配在客户方那边很难申请(国企)。于是只能放弃这个最方便的方案。
2:代码重写·····,是的,最后确实是代码重写,所有使用OpenDataSource的代码都要重写,不再使用OpenDataSource,既然能在程序中使用Microsoft.Jet.OLEDB.4.0,我们就先从SQL中获取数据,保存到DataTable中,然后更新到Access数据库中。一开始我写的测试程序想直接从SQL获取到的DataTable复制一份到Access的DataTable,然后使用Adapter.Update(dt)来更新,但发现行不通,因为每个表的架构都不同,SQL和Access的数据类型转换有很多问题。
看来,想偷懒还是不行,最后无奈之下只能老老实实地一条一条记录Insert到Access中。出乎意料的是,这种方式竟然比使用OpenDataSouce方式的速度更快。于是我猜测,SQL2005中使用OpenDataSource时,每次使用都会重新建立一次与Access的链接,而链接的时间是耗时的,所以整个性能有所下降。
总结:
在使用某种特定技术之前应该要考虑它的使用平台和可移植性,不然会吃大亏,重写这个代码我已经加班好几天了,星期天也在写···
另外,方便的技术不一定是效率好的技术,opendatasource的性能并不比逐行插入到Access的性能要好(这只是我们这个系统所体现出来的)。
版权声明:本文为博主原创文章,未经博主允许不得转载。
运维网声明
1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网 享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com