Is it better to use ADO or DAO in Access 2007?

[For the record, the official name for what once was 'Jet' is now the 'Access database engine'.]

For ACE (the Access2007 engine .accdb format) features it has to be ACEDAO.

For Jet 4.0 features it has to be ADO classic.

For Jet 3.51 features and earlier, pick either ADO or DAO. There are advantages and disadvantages to both. The vast majority of Access database engine functionality is common to both; the mutually exclusive functionality is arguable fringe. A lifestyle choice, perhaps, but no big deal. The smart coder uses the best of both :)

I've used both quite a bit and ADO is my personal preference. It is more modern than DAO, so architecturally it is an improvement: flatter object model, none of the tear down problems of DAO, etc. More properties and methods and introduces events (DAO has none) e.g. for asynchronous connection and fetching of records. ADO recordsets can be disconnected, hierarchical and fabricated, DAO recordsets cannot. Basically, they took the good things about DAO and made them better.

DAO is not without its strong points. For one, you will find more DAO code examples than ADO for Access/Jet.

P.S. for some reason, folk who like DAO really dislike ADO. Ignore the propaganda. ADO isn't deprecated. The ACE has an OLE DB provider and is currently the only way of using ACE in 64 bit. ADO.NET hasn't replaced ADO classic any more than VB.NET has replaced VBA6 in Access projects.

EDIT: just to clarify, "For Jet 4.0 features it has to be ADO classic," this is because DAO 3.6 only received a few enhancements for the features new to Jet 4.0. For example, for the DECIMAL data type you cannot specify scale/precision. Other features are missing completely from DAO. For example, can you do the following in Jet 4.0 using DAO (or ACEDAO in ACE for that matter)?

CREATE TABLE Test (   col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL,    CHECK (NOT EXISTS (                      SELECT T1.col1                         FROM Test AS T1                         WHERE T1.col1 <> '0000'                         GROUP                            BY T1.col1                        HAVING COUNT(*) > 1                      )));

(hint: compressible fixed-width text column with table-level data integrity constraint.) No, you cannot.

AFAIK the only enhancements to ACEDAO was for the new ACE functionality i.e. they didn't go back and fill in the Jet 4.0 gaps in DAO. And why should they? We still have ADO to plug the gaps. Better that the team spent their time more productively, like fixing that annoying DECIMAL sort bug, for me the best thing about ACE ;-)

DAO is the is the recommended technology here. ADO has much been depreciated, and is now being replaced with ADO.net.

Not only is DAO the native and recommended data object model for using MS access, it continues to be enhanced and now has a whole bunch of new features for sharepoint. In access 2007 we now have Support for SharePoint lists. This means that new DAO object model for 2007 allows a sharepoint list to be used and viewed as a SQL server table. That means you can use SQL on sharepoint lists (in fac there not even a oleDB provider that allows you to use SharePoint lists this way, but with DAO you can now do this). There is nothing of this sort that been added to ADO. So SharePoint lists from a access (dao) point of view sees these SharePoint lists as a standard table.

Furthermore DAO in access also has support for what we call complex data types. This was done to support XML lists from sharepoint. Keep in mind for the next version of access (2010) we are going to see a whole bunch more new additional features being added to DAO (JET is now called ACE).

So it is without question that DAO is the correct and good model to use. ADO is not receiving any more enhancements, and has been superseded by ADO.NET.

So the future belongs to DAO, and it’s clear that’s where Microsoft is investing its money in terms of MS access and terms of upgrading Access to work with things sharepoint.

Access 2007 received multi-value capabilities for its field definitions, and again this was a result of enhancements for supporting sharepoint. However, these features are part of JET and these enhancements can be used without sharepoint. they are now part of DAO.

edit:Perhaps I’m going to expand on this a little bit, and try to clarify what we have such opposing answers here, I can assure you that when using access 2007, you’re far better off to use DAO.

Where the confusion stems from, is if you look of the tools references when you choose to use the default data object model access 2007, the problem here is it’s not called DAO anymore. It is now called ACE.

When you use DAO in access 2007 You’ll note in the tool references, the reference is not set to DAO 3.6 ( that version has been depreciated, and also is now not part of MDAC download anymore). You’ll notice that the new reference when using DAO in ms-access is called:

Microsoft office 12.0 access database engine Object Library

Now the above is a bit of a mouth full, but the above is the correct for reference access 2007 when you’re going to use DAO in place of ADO.

In other words, perhaps we should call this DAO II.

In other words, this data engine continues to be enhanced, and will most assuredly see a 64 bit version of this engine for office 2010 (office 14).

So the question or confusion centers around what term were going to use when we refer to using DAO in access 2007. The confusion here is in fact that the documentation and even the tools ->reference does not call it DAO.

At the end of the day in access 2007, if you plan to use DAO then that means that you set the above reference, and do not set a reference to DAO 3.6. Regardless, it makes absolutely no sense to start using ADO now when it’s been depreciated, and the new DAO object model for access continues to be enhanced and invested in by Microsoft.

I hope this helps in clearing up the confusing here. While DAO/JET It’s being depreciated, the new version access 2007 is based on the same code base, except it continues to get enhanced. So the new data engine in access can be considered and called the new DAO object model.

I’m currently under NDA on this issue, but I can most surely tell you that for the next version of office (2010) we are going to see a whole slew of enhancements again.

So it is near unanimous among Access developers that when developing access applications and using the native data engine, the preference here is to use the DAO object model ( but keep in mind we’re not calling it that anymore, we called it ACE).

The answer to the question depends on what you're doing. If you're using Access to work with data that's in a format whose ADO interface is more versatile, then use ADO. If you're using Jet data, or using the Jet database engine to work with another database engine (via ODBC), then DAO is the right choice.

But that answer assumes you're working from Access. If you're working from some other programming environment, the answers will likely be completely different.