5

I'm experiencing some problem when I compile some legacy apps on VB6 since I got a new development machine in windows 7. (my old one was on Windows XP.)

If I compile the project on my XP machine, everything is fine. If I compile the same project on my Windows 7 machine, it still run fine one it, but if I try to run it on a XP machine, I got this error.

Error Number : 5
Description : Invalid procedure call or argument

Thanks to my error handler, I know that the line that throw this error is : 

    Dim objConn As ADODB.Connection
--> Set objConn = New ADODB.Connection

I compared the references on both machines and the Project - References are the same : (Microsoft ActiveX Data Objects 2.7 Library)

What could cause this error?

DavRob60
  • 3,517
  • 7
  • 34
  • 56
  • Not sure, that is a little strange, what happens if you amend it to a single line "Dim objConn As New ADODB.Connection"? – Matt Donnan Jan 20 '12 at 21:33

2 Answers2

4

This is a known problem in SP1 for Win7 which will be fixed in SP2.

The way to handle the issue in SP1 is to copy the old ADO typelib file from Win7 RTM in C:\Program Files (x86)\Common Files\System\ado and register it there.

Registering this old ADO typelib is not a trivial task as numerous forum threads have shown. Here is a batch file we use in our shop to fix ADO typelib issue:

@echo off
set regtlib="%windir%\Microsoft.NET\Framework\v4.0.30319\regtlibv12.exe"
set subinacl="%~dp0subinacl.exe"
set target_dir=%CommonProgramFiles%\System\ado
if not "%CommonProgramFiles(x86)%"=="" set target_dir=%CommonProgramFiles(x86)%\System\ado

copy "%~dp0msado28_old.tlb" "%target_dir%\msado28_old.tlb" > nul
%subinacl% /subkeyreg HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C} /setowner=Administrators > nul
%subinacl% /subkeyreg HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C} /grant=Administrators=F > nul
%subinacl% /subkeyreg HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C} /setowner=Administrators > nul
%subinacl% /subkeyreg HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C} /grant=Administrators=F > nul
%regtlib% -u "%target_dir%\msado28.tlb"
%regtlib% "%target_dir%\msado28_old.tlb"

You need both msado28_old.tlb and subinacl.exe placed in the same folder as the install.bat file and .NET Framework 4.0 setup for the regtlibv12.exe utility.

Now you can recompile your projects referencing ADO on the Win7 box with no compatibility issues on previous versions of Windows.

wqw
  • 11,771
  • 1
  • 33
  • 41
  • Not doubting you, but I'd love to see a link to anything saying they'll get off their duffs and fix this in SP2. As it is SP1 should have been recalled/reissued. I hate to see what other more subtle screwups Win7 SP1 has buried in it. Hmm, maybe I should just follow your link though, eh? – Bob77 Jan 21 '12 at 18:40
  • I see this but no mention of SP2, I'll keep looking though and checking back here. http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx – Bob77 Jan 21 '12 at 18:59
  • They reverted 2.x and 6.0 typelibs and shipped "incompatible" 6.1 typelib for x64 (VBA only) development in Win8 Preview. I think (read somewhere) these will be included in Win7 SP2 too. I mostly don't care as long as Win7 RTM typelib is working -- we are using Win2003 for our build server. – wqw Jan 21 '12 at 21:35
  • Well I agree with a comment that this "solution" may still lead to an endless series of re-posts on this same issue. – Bob77 Jan 21 '12 at 21:57
2

This is a known Microsoft issue, but I don't think it was a bug; I believe compatibility was broken for security reasons. The problem could have existed on a non-SP1 builds if you had a certain hotfix installed. There are a couple of options referenced in the Microsoft KB. Here is another article providing an update.

We ran into this problem and we decided to deploy the Backwards Compatibility patch on all developer machines and replace all legacy ADO references with the Backwards Compatibility reference. This has worked well for us.

UnhandledExcepSean
  • 12,504
  • 2
  • 35
  • 51
  • I'm happy to have waited to test wqw's solution, the solution provided by Microsoft in the 2517589 kb is more *clean* than salvaging old file form the previous version of windows since it clearly identify the new reference as a Backwards Compatibility reference. Thanks again! – DavRob60 Jan 23 '12 at 14:41
  • So know you have to change project references to "backward compatible" typelib, then after SP2 is applied you have to change these back to "regular" typelib. – wqw Jan 25 '12 at 10:22
  • @wqw - I never saw anything from Microsoft stating this would be changed in SP2. Do you have a link? – UnhandledExcepSean Jan 25 '12 at 13:12