Access 2000 ADO query under Windows XP

[Vivitech]

Are there any known Access/ADO issues with this combination?

In order to solve a problem with one of my existing apps, I've narrowed it down to an incredibly simple Access 2000 application containing a tiny bit of querying code called by a 200mS form timer. The same app runs for ever under Windows 2000, but falls over quite quickly under Windows XP.

The errors vary (800401e4 and 3704 are most typical), but they all hint that the recordset I'm using being closed, when in fact there is nothing in the code that could have closed it.

The number of queries that it manages to execute before failing varies too, sometimes only 100 or so, other times up to 3000.

Surely ADO is ADO, irrespective of which OS is being used??
What am or I missing, or at least what else can I try in order to find a work-around?! Our XP-based clients are getting restless!

Thanks in advance...

 

[namliam]

Try using DAO instead its much more stable and such....

Regards

 

[Vivitech]

Not the ADO vs DAO issue again!

But everywhere you look MS (and others) are saying ADO is the way to go!

Surely you aren't suggesting that they would be pushing ADO without having fully tested it under their new "flagship" operating system? If so, maybe they are interested in knowing what I've discovered!

However, just for fun I'll give it a try in my little test app.

Is it OK to mix ADO and DAO recordsets in an application?

 

[namliam]

Yep mixing is no problem, but you have to explicitly declare the recordsets...

Dim rst as DAO.Recordset
or
dim rst as ADO.Recordset

Regards

 

[Vivitech]

It obviously is an ADO/WinXP issue!

Well, well, well!

I changed the code to use a DAO recordset and guess what - it's running happily into 5 figures of looping now.

I guess the problem must lie in the dark recesses of ActiveX and it's tie-in with WinXP?

Oh how I yearn for those good old days of programming, when your application threw up a runtime error you could be pretty sure it was something wrong in YOUR code and not the operating system . How are we supposed to make a living....!

Thanks hugely for the suggestion. I was wasting time tearing my hair out, whereas at least now I can do some useful work ditching the ADO stuff from our application!

 

[Kodo]

did you atleast update the JET to the latest services pack and your MDAC to 2.8? (This is your Data Access Objects core). I'd be interested to see your ADO code.

 

[Vivitech]

But that's exactly the point - it isn't MY Jet/Mdac that "might" need updating is it? It's those on the machines of every one of my customers. What's more, it isn't something I can supply them with. They have to get it from you-know-who.

And what if they don't know how to do the update? Or are too worried to try? Am I supposed to visit them all myself? Plus if other apps on their machine start behaving strangely after the update, that becomes my fault too.

The ever-increasing dependence on a complex operating system (with its numerous versions, service packs and on-the-fly fixes) means there is an ever-decreasing chance of us deploying a stable application to our customers.

Or am I missing something?!

 

[Kodo]

Perhaps an installer would be your solution here for those instances where the MDAC and jet updates weren't up to date.

 

[pono1]

In fact, when you convert to A2003, you'll notice that Microsoft has gone back to defaulting to DAO

Have the mechanics of the Help File (from Access 2000) been improved?

I don't have strong feelings on the ADO/DAO "issue" but for the record I've used ADO in three Access projects and one VB project (all chugging along in production environments) without any fallout...