Question

我在那里

我有这种情况：

a）笔记本：Windows Server 2008 R1，Visual Basic 6，包含所有服务包。

b）桌面：Windows Server 2008 R1（最近更新到sp1，如果它是有罪的话我不知道），Visual Basic 6包含所有服务包。

c）客户端计算机（Windows XP）

我在 a）中创建了一个可执行文件，并将其安装在 c）中。它使用ADO（msado15.dll），它可以在 a）和 C）中正常工作

然后，使用相同的代码，我尝试在 b）（在 b中编译）中执行相同操作，并且它在 b）中工作但在 c）中失败。我确认它与 a）和 b）中的代码相同

简历中：

机器

executable_compiled_in_a.exe WORKS
executable_compiled_in_b.exe WORKS

B机器

executable_compiled_in_a.exe WORKS
executable_compiled_in_b.exe WORKS

C机器（客户机器）

executable_compiled_in_a.exe WORKS
executable_compiled_in_b.exe失败！

错误消息是

Class不支持自动化或不支持预期的接口

并由行

触发

Set Data = New ADODB.Connection

所以，我不知道它有什么问题，两者都使用相同的参考，但 b）生成了不同的可执行文件。

ps：MSDAC_TYP在XP中不起作用，这不是MSDAC的问题，因为a）中生成的可执行文件在c）中有效。

ps2：我也尝试使用msado27.tlb和msado28.tlb，结果相同。

ps3：我的开发者机器（a）和b））是64位，而客户机器是32位。

感谢。

更新

Windows Server 2008 R1的最新服务（我认为与Windows 7相同）更新了ADO版本和可执行文件。简而言之，最新的SP1是邪恶的，并且会带来很多麻烦，至少对于ADO和开发机器而言。

msado15.dll没有Service Pack 6.1.7600

带有Service Pack 6.1的msado15.dll。 7601

Answer 1

typelibs all引用msado15.dll，它本身包含它所属的MDAC / WDAC版本的typelib。每个类型库都描述了不同的ADO接口版本。

通常，您应该使用应用程序所需的最新版本，而不是更新版本。这为您提供最广泛的兼容性。对于很多应用程序来说这意味着2.5，虽然后来的SQL Server支持可能需要2.7或2.8，但在2.6中你可以做的一些事情不是2.5。

不要盲目使用最新的界面。

然而，野外很少有XP机器没有安装2.8。这可能就是为什么MDAC_TYP“不适合你”的原因。

我只能猜测有人在您的一台或两台Server 2008机器上破坏了DAC软件堆栈。可能通过安装禁用UAC的crapware，绕过WRP。或者更糟糕的是使用机器的内置管理员帐户。

否则，根据其中任何一个编译的“msado15.dll”程序（即ADO 6.x）根本无法在XP机器上运行。

事实上，您将Server 2008作为桌面操作系统运行会引发警钟。

Answer 2

在客户端的计算机上安装kb983246。另一种解决方法是使用ADO旧类型库，但它在64位计算机上遇到了kb983246中描述的问题。

Answer 3

将带有SP1的开发者计算机上的SP1之前的计算机中的masado28.tlb复制到某个文件夹（例如，复制到％CommonProgramFiles％\ System \ ado \ PRESP1）。使用Adminstrative权限打开注册表，找到所有值msado28.tlb并将所有值“％CommonProgramFiles％\ System \ ado \ msado28.tlb”替换为“％CommonProgramFiles％\ System \ ado \ PRESP1 \ msado28.tlb”。在更改之前，为密钥管理员设置权限“完全访问权限”。在VB项目引用中使用“Microsoft ActiveX DataObjects 2.8 Library”，在位置：您将看到C：\ Program Files（x86）\ Common Files \ System \ ado \ PRESP1 \ msado28.tlb。现在您可以重新编译VB Application，并且您的可执行文件必须在所有mashines上运行时没有错误。

VB6中生成可执行文件的奇怪问题

更新

3 个答案: