ADO Recordset Crashes VB6 in Windows7

I have a fiarly large VB6 app that I've been maintaining in a Virtual PC session in Window7. Now I'm trying to get it to work with Windows 7 but I've run into a real snag. I've managed to get around all of the other issues presented but this one has me stumped and my searches have not come up with a solution.

The app uses an Access database with a lot of forms using ADO recordsets. During the form load event it hangs when it encounters a requery of a recordset i.e. adodc1.Recordset.Requery then if I attempt to close the application it will crash the VB6 IDE (Visual Basic has stopped working).

Any ideas?

Vic

Welcome to the forums.

The #1 suggestion, which you will not want to hear, is: do not use the ADODC controls.
See this FAQ topic, though it doesn't answer your question.

I'm not quite as "death on everything VB" as some of these guys, i.e. databound controls are really the guts of the greater VB concept of RAD and the reason VB was developed.

However there are a number of snags that relate to holdovers from earlier versions of VB before VB6, the grim spectre of DAO that still has it hooks too deeply into VB as of VB6, changes to Windows and to MDAC over the years, etc.


There are challenges involved in continuing to use VB6 today. The whole data binding arena is just one of them. You must be sure to use the latest VB6 service pack and then you have to adhere to the guidelines, detours, band-aids, etc. provided in MS KB articles over many years.

Even limiting ourselves to the ADODC we can find many KB articles. Here's an important one:

FIX: ADO DataControl and DataEnvironment Events Only Work with ADO 2.0

Another:

PRB: IRowsetNotify Error with ADO Data Control and ADO Recordset


The alternative is to sacrifice many of the RAD capabilities in VB6, and use it as if you were writing in a more primitive system like VBScript or C or something. This is fine for many hobbyists, since they aren't using it for what it was intended most of the time anyway: a RAD database front-end tool, similar to PowerBuilder and such. It even applies to many professional developers who don't want to spend all of the extra time and effort C/C++ require but want to create non-database programs in a higher level language.

There may be a resolution to your problem without the radical surgery of ripping out the ADODC and data binding. Without seeing some code it mgiht not be easy though, and even then the problem might relate to one of the subtle flaws introduced in the ecosystem since 1998.

Unlike MS Access, VB was never updated past VB6 to address these problems. All we have are the service packs and the suggestions in those KB articles to work with now.

Dilettante, Thanks for the reply! I think this must be some kind of incompatibity with something in this app so it's going to take some time to puzzle this out. I put together a test program that just creates an ADO recordset and navigates through it. The requery didn't cause any problem.

Vic

I wouldn't expect a problem with a bare Recordset. The problem is when you add ADODC to the mix it gets hairy.

From what I can tell ADODC was compiled against ADO 2.0 until VB6 SP4. At that point you have a version compiled against ADO 2.5, which has been the base feature level of ADO for a long, long time. You'll want to reference ADO 2.5 in your program.


This is part of why the ADODC is obsolete. As SQL Server evolved it needed a number of hacks and kludges and new features in ADO. Thus for SQL Server beyond 7.0 you may need ADO 2.6 or later, which can result in mismatches with the ADO 2.5 version of the ADODC and will really be far off with the ancient ADO 2.0 version.

It's really all part of the orphaning of VB6 by Microsoft.

Dilettante,

Interesting! I changed the 2.8 reference to 2.5 and I'm having the same result.

I did notice that if I comment the requery so it hits the Adodc1.Refresh , it will then take the error path with the error "The object invoked has disconnected from its clients". Does this give you a clue as to what might be wrong?" When I google this message it apears that it can be a lot of things and I didn't find anything specific to my situation.

BTW - I'm not using bound controls, I'm populating everything using code.

Thanks,

Vic

I'm not sure why you'd ever use the ADODC if you aren't binding it to another control. That's its primary role: a data binding datasource.

If you can construct a small sample program that reproduces the problem it might be easier to track down, and if you post it here people might help resolve it quicker.

>> I'm not using bound controls, I'm populating everything using code.


Dilettante, Sorry that statement is not entirely true. Most of the forms are Tabbed forms and on some of the tabs they will be unbound but on others they are bound. Mostly using Farpoint Technology Systems spreadsheet control.

I'm not feelling well and I think my brain quit on me.

I',m putting together a sample program but I don't think I can post it since it is using Farpoint controls.


Vic

Well maybe somebody else will read through this and have a lightbulb come on. I'll poke around a little more myself.

Dilettante,

The crash is associated with the Sheridan Grid Control. The app has a number of bound grids using this control.

The setup program for this control does not run in Windows 7 even using compatibility mode. To get it installed I registered each of the OCXs and I also had to export the license information from the registry of an XP machine and import it to the Windows 7 (64bit) machine to get it to run. I'm fairly certain this process is successful because the licence message is no longer displayed and I see the registry entries in the 32bit registry. I also see these license entries in the 64bit registry.

It looks like there are bigger problems with the Sheridan controls then installation. Sheridan was bought out by Infragistics.

Vic