# DAO and ADO in Access



## downwitchyobadself (Oct 13, 2000)

I have an Access 2000 app that may need to be converted, depending on the speed return. It's a time-critical thing, and I've done just about everything I can think of, MS can (seem to) think of, and the wonder-workers of Getz and Co. have offered, to speed it up.

Anyone out there (and you know who you are) have any experience converting DAO to ADO? Did it help? Any good _detailed_ sources of information out there in web-land or manual-land?

Your time and insight is always appreciated.


----------



## YSB (Mar 7, 1999)

In general DAO is faster and more efficient than ADO when dealing with Jet. ADO is much more bloated because it was designed to handle many types of DB engines at once. If the DB is Access then ADO might even slow you down more. If the DB is ODBC and just the app is Access than ADO might be the better choice (and maybe even the only choice) as DAO was only designed to handle Jet. Before ADO came around, non Jet engines where handled with RDO which Access I don't believe supports. ADO was created so that the same objects can work with all engine types, even Jet, by just changing some object properties. The extra capability also means slower code. When an Access app is dealing with an Access DB it returns DAO data objects by default. This means that using ADO with an Access DB must deal with both the slower ADO plus the overhead of converting the default object returns to ADO. If you have a lot of VB code that accesses data then you have the additional job of rewriting the code to work with ADO. That would mean changing all objects to the ADO equivalent, rewriting all code that deals directly with the objects properties as parallel DAO objects and ADO objects often have different properties, changing a lot of methods (for example DAO's FindFirst and ADO's Find work very differently), and dealing with a lot of debugging to find all the code you missed. 

In short, if you have an Access DB stick with DAO. If speed is a big issue, the only real solution would be to move to a real network-based server-side DB like SQL Server or Oracle. The front-end could still be Access 2000 thanks to the new Data Project features although you might get more efficiency with with VB6.

To be honest, I have never compared the speed of ADO and DAO myself but if even MS admits that ADO is slower for Jet DBs they're probably right.

Good Luck!


----------

