公司本身的系统为BS架构，用SQL2005和VS2003开发。公司也根据网络版开发了相应的单机版软件，使用Access数据库。客户方希望能在网络版上做的工程导出到单机版使用，单机版做完后再导入到网络版。于是便产生了导入导出的任务。
导入导出的代码我们决定在BS架构上完成，于是便产生了下面的程序代码：
我们的方法是在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文件：
发现竟然没有报错，而且可以使用这个链接来访问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的性能要好（这只是我们这个系统所体现出来的）。