infosysgmbh
asked on
Problem using DAO and ADO together
We are currently converting a large VB Project from DAO to ADO. For a limited period of time, we need to use DAO and the VB DAO Data Control to bind our grids to. For the detail data we use already ADO (both DAO and ADO via jet). What we found is, that when we update the database via ADO, it takes around 5 seconds until we can access the new data with a DAO.Openrecordset. Is there any way we can make sure that ADO really flushes the data to the database and that DAO is able to read the data right after it has been written by ado?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thui, you're a legend, I spent 3 days trying to fix a problem using SQL commands and ADO in a program. I was getting the error "Could not update, currently locked". It fixed most of my problems.
I've also been working with Microsoft's support because there's so little valid information in their help - I'm finding that in many cases their sample code provides only the DAO methods; or what seems to be conflicting methods; but as it turns out there are several correct ways to code ADO controls. Which only confuses me more.
What database and version are you using? (There are also some known issues with DAO code and Access 2000.) Are you sure you have the right provider selected in your data environment properties? And that you've correctly set up the command properties for datamembers? I've found optomistic locking works best.
ADO, if it's set up correctly will automatically write new and edited data to the database when a user moves from one field or row to another. But the method used by ADO causes conflicts when also using DAO controls and code. If you're able to commit data via ADO controls but it's taking too long to read that data with DAO controls I'd guess there is some conflict with the conflicts with your connection methods as you're actually accessing the database via two different connections.
Also since ADO allows you to define rowsource, rowmember and listfield properties for populating lists in the DataList and DataCombo controls and define different datasource, datamember and datafield properties for the data tables to save data to; and DAO doesn't alloow this, it could be another area of conflict.
Fortunately for me, my application isn't very complex yet, so I'm trying to go back a re-do forms where I used DAO so my application will be completely ADO.
Based on what I've been discovering about DAO to ADO conversions, I think if I had to convert a large complex application from DAO to ADO I'd do it as a major version update and not release a version with combined methods. I'd wait to release until everything is converted to ADO.