I have an application which is both in active use and is undergoing further major development. It uses DAO. The current advise seems to be to use ADO. Can I simply add ADO to the reference list as well as the existing DAO 3.6 reference - or will this cause any sort of conflict? If I do this should I list DAO higher than ADO to ensure the current code works or??


Peter

You can have them both, but list DAO higher. That has been my experience. I am sure there are other more experienced users with other advice. I would change to all one or the other though. DAO would be the choice there. The latest and greatest Access development book by Microsoft references strictly DAO throughout, much to my chagrin.


mmcdonal

Hi Peter,

Better yet, just fully qualify your object variable names to keep things straight in your code. For example, DAO and ADO both use a recordset object. So when you declare one, use:

Dim rstADO as ADO.Recordset or Dim rstDAO as DAO.Recordset.

That way you can forget about the references dialog hierarchy, and ensure you're getting the right oject when you need it. Much simpler.

I'm not sure what type of app your developing, but if you are using the Jet engine as your data source, THERE IS ABSOLUTELY NO GOOD REASON TO USE ADO IN PLACE OF DAO!!! ADO IS NOT better 'cause its newer, or anything else like that. DAO is optimized for the Jet database engine. Using ADO in this context buys you nothing. Just felt like saying that, in case your doing an all Access app.

Bob

Thanks - DAO it is!
Peter

Peter

That's right Bob. ADO actually calls out of Jet and instantiates a new process outside of Access that Access has to maintain contact with. It therefore uses its own memory and other resources as a seperate process from Access.

ADO is better for Access/SQL an VB.NET development it seems.



mmcdonal

Yup. DAO is the application programming interface (API) for the Jet engine. ADO and ADOX are APIs for the OLE DB Provider for the Jet engine, or any other data source that has an OLE DB Provider written for it.

ADO and ADOX objects map to OLE DB objects (COM components that run in their own process). ADO and ADOX pass OLE DB SQL statements to provider specific OLE DB functions that translate OLE DB SQL into provider specific SQL.

DAO objects just map to Jet. The DBEngine object in the DAO object hierarchy is the Jet engine. DOA just talks to Jet in Jet SQL. Access itself still uses DAO internally. If you retrieve the recordset of a bound Access form, you get a DAO recordset in a .mdb (an ADO recordset in a .adp).

Granted, both DAO and Jet have been deprecated to technological purgatory maintenance mode. But neither is "more obsolete" than the other. They were made for each other. As long as Jet is around, DAO is the preferred API for working with it (caveat: depending on whose opinion you're reading at the moment).

Opinions aside though, I don't think anyone would recommend rewriting a DAO app in ADO, or adding ADO midstream, then figuring out how to disambiguate DAO and ADO objects. In a new app, probably don't matter tremendously which you use. Most of the MDAC code I post on this forum is in ADO, simply so I don't have to start every post with "Don't forget to set a reference to the DAO 3.6 object library", ADO being the default and all.

Bob

  ADO was designed primarily as a set of data access classes for client/server apps enabling a connection to any backend data source with an OLE DB Provider written for it (this includes Jet). DAO can't Access data sources other than Jet in a client/server architecture without the use of pass-through queries and an ODBC driver.

Apps built on the .NET Framework employ ADO.NET, whose classes comprise the System.Data namespace. The System.Data namespace includes three "sub" namespaces that target distinct classes of data providers:

System.Data.SqlClient - The .NET Framework Data Provider for SQL Server.

System.Data.OleDb - The .NET Framework Data Provider for OLE DB. To connect to Jet from a NET app, you would use the System.Data.OleDb.OleDbConnection class to connect to the Jet OleDb provider. You can also connect to SQL Server using the OleDbConnection class, but the System.Data.SqlClient.SqlConnection class is designed for that purpose.

System.Data.Odbc - The .NET Framework Data Provider for ODBC data sources (though this set of classes was only supported in version 1.1 of the Framework.)

Yup, before too long ADO and ODBC will also be depracated to technological purgatory maintenance mode.

Bob