Have you been successfully compiling programs using Visual Basic 6 under Windows 7 in the past, only now to find that the following events now occur:
- programs using Microsoft ActiveX Data Objects (ADO) / MDAC now crash with an automation error when running on Windows XP?
- the Package and Deployment Wizard hangs after you select a directory to save your package to?
Wondering what changed to break your previously working system? Well, if you had just recently installed Service Pack 1 for Windows 7, then you likely have run into the same issue I have. Read on for my own experiences and solution…
It seemed simple enough: I made a seemingly minor change to a program I’ve compiled dozens of times. This program uses Microsoft ActiveX Data Objects, but the change I made to the program touched nothing related to data access at all. As a matter of fact, I had taken a working code snippet from one project and applied it to another similar one. Nothing here was untested code. After what seemed like a normal compile, I attempted to deploy my updated program to a standard Windows XP system (running Service Pack 3) by copying the executable file over our network as I always do. When I launched the executable, however, I was graced with the following error:
‘Error 430 Class does not support automation or does not support expected interface’
Interestingly, I had been in the habit of placing line numbers in some sections of my source, in order to help with the trapping of just this kind of unexpected error. The line number is referenced pointed me to the following line of code:
Set ADOConn = New ADODB.Connection
Huh? This was a line of code I’d used in tons of different projects and never once had any trouble with. So, knowing that couldn’t really be the issue, I set off to try everything else I could think of to get this working. After removing and adding back all references and components in my project, I still had the same issue. I next reinstalled the MDAC 2.7 package on my target PC. Again, no change in the error at all. Finally, I attempted to run the Package and Deployment Wizard on my project, so that I could totally reinstall it on the target machine, in case a file or library there had become corrupted. After the first few screens, it just hung. Subsequent tries resulted in the same lock-up, happening right after I selected the folder to place the package in. My system seemed to be falling apart for no apparent reason!
At that point, I turned to Google for aid. From the results I found there, it seemed that a number of persons had begun experiencing the automation error issue after having installed Windows 7’s Service Pack 1. Apparently, that Service Pack changes the way the data access components are referenced in program, making them no longer compatible with the matching version level installed on an XP system. You’d never notice this, however, if you were testing the program on your Windows 7 system, as the errors only happen when you move it to an XP system. Thanks, Microsoft! :/
The main recommendation I found was to simply remove the Service Pack. As a virtualization user, however, I felt like I had a viable alternative: I had long ago installed Visual Studio 6 in Windows 7’s XP Mode. Since VB6 runs fairly well under XP, and since XP is not going to get many more major updates, I’d be insulated for the most part from the effects of any future, major Windows 7 updates. I also wouldn’t have to lose out on any benefits I had gained from the Service Pack, nor would I have to exert vigilance in order to keep Windows Update from giving it to me again. Upon compiling the project in XP Mode, I was able to copy the executable to the target machine and run it with no issues at all. So, from now on I’ll be running my VB6 exclusively under Windows 7’s XP Mode.
Please note that I never did find any other articles linking the issue I began experiencing with the Package and Deployment Wizard and the Service Pack. But, this was something I’d used often prior to the installation of the Service Pack. I have to believe that there is a correlation, at least as regards projects which use the MDAC. I haven’t tried it with non-MDAC-using projects, as at this point I really don’t care: if I’m going to use XP Mode for VB6, I may as well use it for the whole suite!
Windows 7’s SP1 breaks VB6’s ability to use ADO correctly on programs you try to run under Windows XP (or perhaps any other prior version of Windows). It may also break the Package and Deployment Wizard. So, either remove SP1 or run VB6 under XP Mode or an XP VM in any other virtualization program you like.