Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
Access VBA Discuss using VBA for Access programming.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access VBA section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
  #1 (permalink)  
Old January 4th, 2006, 11:06 AM
Registered User
 
Join Date: Jan 2006
Location: Oakville, Ontario, .
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default ADO - DAO compatability

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
  #2 (permalink)  
Old January 4th, 2006, 12:45 PM
Friend of Wrox
Points: 9,611, Level: 42
Points: 9,611, Level: 42 Points: 9,611, Level: 42 Points: 9,611, Level: 42
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Mar 2004
Location: Washington, DC, USA.
Posts: 3,069
Thanks: 0
Thanked 10 Times in 10 Posts
Default

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
  #3 (permalink)  
Old January 4th, 2006, 09:52 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Hi Peter,

Code:
If I do this should I list DAO higher than ADO to ensure the current code works or??
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

  #4 (permalink)  
Old January 9th, 2006, 09:28 PM
Registered User
 
Join Date: Jan 2006
Location: Oakville, Ontario, .
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thanks - DAO it is!
Peter

Peter
  #5 (permalink)  
Old January 10th, 2006, 08:13 AM
Friend of Wrox
Points: 9,611, Level: 42
Points: 9,611, Level: 42 Points: 9,611, Level: 42 Points: 9,611, Level: 42
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Mar 2004
Location: Washington, DC, USA.
Posts: 3,069
Thanks: 0
Thanked 10 Times in 10 Posts
Default

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
  #6 (permalink)  
Old January 10th, 2006, 04:30 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

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

  #7 (permalink)  
Old January 10th, 2006, 06:06 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

 
Quote:
quote:ADO is better for Access/SQL an VB.NET development it seems.
Quote:
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






Similar Threads
Thread Thread Starter Forum Replies Last Post
ADO or DAO knowledge76 Access VBA 3 October 12th, 2015 04:26 PM
DAO vs. ADO SerranoG Access VBA 11 December 5th, 2006 01:19 PM
Dao to Ado vrtviral Access VBA 5 February 19th, 2005 11:13 AM
ADO vs DAO perrymans BOOK: Expert One-on-One Access Application Development 0 October 24th, 2004 11:36 PM
DAO / ADO? merguvan Access VBA 8 January 18th, 2004 07:39 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.