I there
I have this scenario:
a) Notebook :Windows Server 2008 R1, Visual basic 6 with all service pack.
b) Desktop : Windows Server 2008 R1 (recently update to sp1, i dunno if it is the guilty), Visual basic 6 with all service pack.
c) Client machine (Windows XP)
I created an executable in a) and installed it in c). It uses ADO (msado15.dll) and it works fine in a) and in C)
Then, using the same code, i tried to do the same in b) (compiling in b) ) and it work in b) but it fail in c). I verified that it is the same code in a) and in b)
In resume:
A machine
- executable_compiled_in_a.exe WORKS
- executable_compiled_in_b.exe WORKS
B machine
- executable_compiled_in_a.exe WORKS
- executable_compiled_in_b.exe WORKS
C machine (customer machine)
- executable_compiled_in_a.exe WORKS
- executable_compiled_in_b.exe FAIL!
The error message is
Class does not support Automation or does not support expected interface
and is trigged by the line
Set Data = New ADODB.Connection
So, i don’t get it what is the trouble, both uses the same reference but b) generated a different executable.
ps: MSDAC_TYP DOES NOT WORK IN XP and it is not a problem of MSDAC because the executable generated in a) works in c).
ps2: i also tried using msado27.tlb and msado28.tlb with the same results.
ps3: my developers machines (a) and b) ) are 64bits, while the customer machine is 32bits.
Thanks.
Update
The latest service of Windows Server 2008 R1 (and i think the same for Windows 7) update the version of ADO and the executables. Short story, the latest SP1 is evil and will bring a lot of trouble, at least for ADO and development machines.
msado15.dll without service pack 6.1.7600
msado15.dll with service pack 6.1.7601
Install kb983246 on your client’s machines. Another workaround is to use the ADO old type library but it have the issue described in kb983246 on 64bit machines.