AddThis Social Bookmark Button


Listen Print

News

by Helen Feddema
02/01/2000

  1. Maturity: DAO is a mature technology, with the bugs worked out. ADO, on the other hand, is brand-new and still quite buggy. Many developers (and ordinary users!) would prefer to wait out the v. 1.0 stage, and defer using ADO in real-life applications until it is more stable.

  2. Your code library: If you have been doing Access development for a while, you probably have a stock of DAO code segments you can pop into new projects; switching to ADO will require learning new syntax and developing code from scratch. Why abandon your investment of time and effort?

  3. Working with Access 97: If you are writing code (say VBS code on an Outlook form) that may work with either Access 97 or Access 2000, DAO will work, but ADO won't, since Access 97 doesn't support ADO. Outlook forms are substantially the same in all versions of Outlook, and Outlook VBS code can run in all versions of Outlook too, so long as recently introduced language elements are avoided. Using DAO to communicate with Access from Outlook VBS ensures that your code will run with either Access 97 or Access 2000.

  4. Form and report recordsets: Form and report recordsets in Access 2000 still use DAO exclusively, so you must use DAO to work with recordsets and recordset clones. Since you must use DAO for these purposes (for example, to synchronize a form with a record selected in a combo box in a form header), it is a lot simpler to just use DAO for all your coding, to avoid confusion between the two object models.

  5. Class prefixes: If you work with both the DAO and ADO object models, you must prefix all objects that belong to both object models with the appropriate class name or you may have an error in running your code. This happens because of objects (like the Recordset object) which belong to both object models, but which have different properties or methods in DAO and ADO. If you stick to the DAO object model, you don't need to use class prefixes; just make sure that DAO is checked in the References dialog and ADO is not checked.

  6. ISAM and ODBC connectivity: DAO is designed specifically for the Jet database engine, and thus incorporates ISAM and ODBC connectivity, making back-end providers look as much like native Jet as possible. This allows for easier coding (no need for lots of special cases).

  7. Performance: DAO is much more efficient at using the Jet engine than ADO--as much as 5 to 10 times faster. Faster performance is always welcome! Additionally, all DAO objects you create use the same Jet session, while in ADO every Connection object and ADO Data control uses a separate Jet session, which can lead to Jet running out of resources. This is an important consideration, at least if you need to use lots of objects in a project.

  8. Distributing applications: When using DAO, only a small set of files must be distributed to users' computers. When distributing ADO, all of ADO and OLE DB (including ODBC) must be included in the setup files package. The smaller the distribution package, the better, especially if you must use floppy disks for the setup files.

  9. Wild Cards and Stored Queries: Because ADO uses different query wild-card characters than DAO, stored queries created in DAO won't work in ADO (at least if they use wild cards). So, if you don't want to have to replace all the wild cards used in queries with the new ADO wild cards, stick to DAO.

  10. Security: DAO has a full Security model, but ADO has no way to specify the PID. If the System.mdw file is deleted, you can't recreate security accounts from scratch, and if you don't have a usable backup System.mdw, you are stuck.

  11. If it ain't broke....: Sometimes it seems as though Microsoft changes things just for the sake of change. Why else would the set of developer tools that accompanies Access have a different name and acronym with every release? This set of tools was called ADK for Access 1.1, ADT for Access 2.0, ODT for Access 95, ODE for Access 97, and now MOD for Access 2000. It's not exactly the same, but DAO is a robust and highly functional object model. So long as you are working with Access data sources, there is no need to move to ADO yet.