由于历史原因，我们在两个相同的Windows 2008服务器盒上运行了一些传统的vb6服务器端代码，这些服务器盒使用dao 3.6来访问后端MS访问数据库。这已经好多年了，我们目前正在迁移所有代码。但是，代码运行的其中一个服务器变得越来越复杂，因此我们需要将代码移动到新服务器，因为迁移的解决方案暂时还没有准备好。 工作正常的服务器运行Windwos Server Web 2008 Sp1 64位。新服务器是Windows Server Standard 2008 R2 Standard Sp1。 在这台新服务器上运行测试时，我们开始在应用程序中进行随机冻结。有一个简单的循环在数据库中的每个表上运行一个select查询。添加一堆日志后，它在调用DAO.Database对象的OpenRecordset方法时冻结。有时它会冻结几秒钟，其他时间会冻结10到11分钟，然后继续。正在运行的查询采用这种格式，并且都应返回0条记录：
SELECT * FROM BlahBlah WHERE WriteTime > #25 Oct 2012 10:09:43#
直接在数据库上运行（即在Access中），它们返回正常。它不是每次都锁定的查询。我认为它可能是我们的软件特有的东西，我没有设法跟踪，直到我在这里找到一个非常相似的帖子（遗憾的是除了我的没有回复！） http://www.vbforums.com/showthread.php?653166-Using-Dao-3.6-on-Windows-server-2008&highlight=dao+3.6+server+2008
到目前为止我唯一发现的是它运行的服务器上的DAO360.dll版本是3.60.9704，而有问题的服务器上的版本是3.60.9756（即Dao的新版本） ）。我没有手动安装或注册任何东西，但在新服务器上安装了Access 97和Access 2003，与旧服务器相同。我还应该指出，如果我将后端代码按原样移动到旧服务器，那么测试工作正常，所以我很确定它不是代码。
现在我知道DAO已经过时了，但我仍然坚持使用这个代码库，直到迁移的解决方案可用并经过全面测试，因此任何关于在哪里寻找的想法都会非常受欢迎。与此同时，我将尝试在新服务器上手动注册3.60.9704版本并运行更多测试以查看是否存在问题，但如果它是......那将会有点奇怪。
答案 0 :(得分：1)
当我进一步了解它时，代码运行良好的服务器是Windows 2008网络服务器，虽然它是64位，但是与Windows Server新机器上的操作系统完全不同的野兽2008 R2。解决方案似乎是回到服务器上的旧操作系统，而不是重写整个应用程序，这对我们来说很容易。 幸运的是，这只需要运行几个月左右，因为整个事情正在被重写。