Recordset ? defaults mdb->DAO, adp->ADO

[David P. Lurie]

Why does the form recordset seem to default to DAO in an MDB and ADO in adp?

I'd like to have ADO features by default in mdb forms. The combo box wizard
uses DAO for mdb and ADO for adp. Does the first control on the form that
uses either DAO or ADO set this feature for the form?

Can this be changed, or do I need to rebuild the forms in question?

Thanks,

David P. Lurie

 

[Dirk Goldgar]

Why does the form recordset seem to default to DAO in an MDB and ADO
in adp?

Because in an MDB, Access uses DAO to manage the data, while in an ADP
it uses ADO.

I'd like to have ADO features by default in mdb forms.

Why? When workiong with Jet databases (that is, tables stored in .mdb
files), DAO is both more efficient and more powerful.

The combo box
wizard uses DAO for mdb and ADO for adp. Does the first control on
the form that uses either DAO or ADO set this feature for the form?

No, it's just the way Access works.

Can this be changed, or do I need to rebuild the forms in question?

In an .mdb, you can open an ADO recordset and bind the form to it, by
setting the form's Recordset to the ADO recordset you opened. I see no
value in doing this, though, if your data is stored in an .mdb file.

 

[David P. Lurie]

Because in an MDB, Access uses DAO to manage the data, while in an ADP
it uses ADO.


Why? When workiong with Jet databases (that is, tables stored in .mdb
files), DAO is both more efficient and more powerful.


No, it's just the way Access works.


In an .mdb, you can open an ADO recordset and bind the form to it, by
setting the form's Recordset to the ADO recordset you opened. I see no
value in doing this, though, if your data is stored in an .mdb file.

--

Thanks for your assistance.

I have been developing an application with Access 2003 as front end,
initially using MSDE backend, now trying postgresql, accounting for the
change from adp to mdb.

The reason for ADO only was that "Programming Microsoft Access 2003" by Rick
Dobson (Microsoft Press) advised ADO rather than DAO. The author stated that
DAO would not be updated further, and implied lack of future support for
DAO.

I found the DAO vs. ADO difference when cutting and pasting forms from the
adp to mdb. No problems converting; just changed record sources as needed
and Find (ADO) to FindFirst(DAO), etc.

David P. Lurie

 

[Dirk Goldgar]

Thanks for your assistance.

I have been developing an application with Access 2003 as front end,
initially using MSDE backend, now trying postgresql, accounting for
the change from adp to mdb.

If you use linked tables and bound forms, Access is going to be using
DAO to connect them.

The reason for ADO only was that "Programming Microsoft Access 2003"
by Rick Dobson (Microsoft Press) advised ADO rather than DAO. The
author stated that DAO would not be updated further, and implied lack
of future support for DAO.

At this point, plain ADO is just as "dead" as DAO, as MS is now pushing
ADO.Net, which is substantially different. Although Jet is on
maintenance support (as I understand it) and DAO is not expected to
receive any further enhancements, I am told that DAO and Jet will
continue to be supported in the realistic sense that Access will be
using them, for at least the next release after 2003.

I found the DAO vs. ADO difference when cutting and pasting forms
from the adp to mdb. No problems converting; just changed record
sources as needed and Find (ADO) to FindFirst(DAO), etc.

Yes, converting is quite simple. Since you're working with an ODBC data
source, watch out for slightly different behavior in recordsets, such as

+ The RecordCount property not accurate until you've navigated to
the end of a recordset.

+ Values of autonumber fields (or equivalent) not available
immediately after Recordset.AddNew -- you have to call .Update, then
move to the .LastModified record.

+ Also, if you're working with a DAO recordset you must call the
..Edit method before modifying field values.