What does DAO have that ADO/ADOx/JRO do not?

by Michael S. Kaplan, published on 2007/07/13 15:11 +00:00, original URI: http://blogs.msdn.com/michkap/archive/2007/07/13/3849288.aspx

If you don't care about Jet or DAO or Access then this is a post you can skip! 

This post is a reposting of an article written over seven years ago, and is still entirely true.

A few versions ago, the Access team started formally backing away from de-emphasizing DAO and once again was adding it to default references in new databases.

As a culmination of this slow change, the updated version of DAO that is specifically used by Access 2007 and ACE is now once again under active development.

Proof positive that rumors of DAO's (and Jet's) death were greatly exaggerated? :-)

Microsoft has clearly positioned ADO as the replacement to DAO.... many Microsoft representatives have gone to far as to state that DAO is DOA (Dead On Arrival, a term used in the US to describe people who are dead when an ambulance arrives hoping to take them to be saved). HOWEVER a lot of core functionality is supported in DAO that ADO/ADOx/JRO do not support, and might never actually support since Microsoft seems to be pushing customers in other directions. While Jet itself will not "die" it is clear that it is no longer a strategic platform, so there simply does not seem to be enough interest to make things work more effectively in Jet.

Here, for the full record, is a list of all of the capabilities DAO has that ADO does not:

• Running transactions that use multiple databases (works in DAO since transactions are at the Workspace level, fails in ADO since transactions are at the Connection level -- and Connections only support one database)
• Opening a table in a mode that keeps others from opening it read-write mode (works in DAO through use of the dbDenyWrite constant, fails in ADO at the table level since its closest analogue adModeShareDenyWrite only can be set at the Connection level).
• Opening a table in a mode that keeps others from opening it at all (works in DAO through use of the dbDenyRead constant, fails in ADO at the table level since its closest analogue adModeShareDenyRead only can be set at the Connection level).
• Creating users and groups in a way that allows you to recreate them in case an MDW file is lost (works in DAO using CreateUser/CreateGroup which allow you to specify PIDs, fails in ADO which does not allow you to specify PIDs).
• Securing Access project objects such as forms, reports, or macros (works in DAO through the Permissions property on Document objects, fails in ADOx because it does not properly map the expected constants for permissions to execute, read changes, and write changes to these object types).
• Ability to create a linked ODBC table that is updateable (works in DAO through its call to the SQLStatistics function, fails in ADO which makes no such call).
• Ability to create "Prevent Deletes" replicas (works in DAO by passing the value of &H4 to the CreateReplica call, fails in JRO, which has no such analogue).
• Method for determining folder information from Exchange/Outlook folders and columns (works in DAO through the Attributes of the TableDef/Field objects, fails in ADO since this information is not passed on).
• Capability to set and change Jet options without making registry changes (works in DAO through DBEngine.GetOption and DBEngine.SetOption, fails in ADO, which has no such analogue).
• Allowing the creation/change/deletion of any and all properties through the JPM -- also known as the Jet Property Manager (works in DAO through CreateProperty/Properties.Append, fails in ADO/ADOx/JRO for almost all properties since there is no hookup of the JPM to ADO).
• Forcing the locking mode of a database when working from within Access (works in DAO through the DAO.LockTypeEnum constants while using CurrentDb, fails through the ADO.LockTypeEnum constants while using CurrentProject.Connection).
• Retrieving implicit permissions on an object (works in DAO through the AllPermissions properties, fails in ADO which has no AllPermissions property and requires you to separately enumerate the user and all of their groups).
• Allowing a separate Jet session to run using a special object in the object model (works in DAO through the PrivDBEngine object, fails in ADO due to no analogous object).  

This post sponsored by Ｄ (U+ff24, a.k.a.FULLWIDTH LATIN CAPITAL LETTER D)

referenced by

go to newer or older post, or back to index or month or day