Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DAO vs Ado 3
- Thread starter draugen
- Start date
HarleyQuinn
Programmer
To save a bit of typing, a very quick search on this forum and google turned up thread705-1310439, and this link. They should be of some help to you.
Hope this helps
HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!
You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman
Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before posting.
Hope this helps
HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!
You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman
Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before posting.
-
2
- #3
dilettante
MIS
DAO is an older technology developed as Visual Basic progressed to VB5. It is an interface to the Jet database engine used in VBA and in VB.
It was supplemented by RDO which provided an interface to other kinds of databases.
In the mid to late 1990s Microsoft began working on a replacement for DAO and RDO. A lot of new non-VBA programming environments began cropping up (VBScript, JScript, VFoxPro began to broaden, VJ++, etc.) and the need for a generalized data access technology was seen too.
When VB6 was released ADO still lacked many capabilities, but at the 2.0 level it was complete enough for some purposes.
ADO Compared with RDO and DAO
That was late 1997 though. By the time 1999 rolled around ADO 2.1 was established and it addressed many of these limitations. Very soon ADO 2.5 came out (and shipped with Windows 2000) and became the baseline release of ADO up until today. ADO 2.5 was pretty much feature-complete, consisting of not only ADO itself but also ADOX, ADO MD, and JRO (a Jet supplement to ADO).
Since ADO 2.5 there have been a number of refinements and some important minor features, but basically ADO 2.5 is the core level of functionality. Nothing earlier is discussed much anymore. ADO History.
One major advantage of ADO for relational database access was an escape from the non-performant world of ODBC, an ancient Microsoft low level data access technology. This was replaced by more the powerful and versatile OLE DB Provider approach, which can use more efficient and more flexible client to database server communication and is not limited to relational datastores.
There is an adapter layer Provider called MSDASQL and it is the default Provider. It is there as a shim between ADO and old-style ODBC drivers for compatibility.
The only people who should be using DAO are probably those still migrating VB5 programs to VB6 and those supporting VB6 programs still bound to the old technology. MS Access 2007 breathed some new life into DAO for VBA programs, but as far as I know this only applies to VBA hosted in Access 2007.
VB6 was a transitional release of Visual Basic. Because of this there are some controls that only work with DAO and others that only work with ADO, and a number of controls that can work with either for simple data binding.
We never did get a real VB7, VB8, etc. that would most likely have phased out internal support for DAO entirely. For VB6 programming DAO may remain viable if care is observed (try to use DAO 3.6, the final release circa 1999). There are some issues with running VB6 DAO programs on WinXP64 and Vista64. It may even be impossible, but you might get the 32-bit DAO 3.6 to install and run under WOW64 on those OSs.
DAO is pretty much limited to working with Jet MDBs and perhaps with ACE ACCDBs (Access 2007) if you install the necessary Office 2007 components. DAO does allow a sort of limited access to ODBC "pass through" tables to reach other relational databases too.
RDO is pretty much dead.
ADO still does not offer 100% of the functionality that DAO provides for Jet MDBs, but the gap is pretty narrow. ADO can also be used to do things never imagined with DAO.
The controversy over DAO vs. ADO continues to this day, more than 10 years after VB6 was released.
It was supplemented by RDO which provided an interface to other kinds of databases.
In the mid to late 1990s Microsoft began working on a replacement for DAO and RDO. A lot of new non-VBA programming environments began cropping up (VBScript, JScript, VFoxPro began to broaden, VJ++, etc.) and the need for a generalized data access technology was seen too.
When VB6 was released ADO still lacked many capabilities, but at the 2.0 level it was complete enough for some purposes.
ADO Compared with RDO and DAO
That was late 1997 though. By the time 1999 rolled around ADO 2.1 was established and it addressed many of these limitations. Very soon ADO 2.5 came out (and shipped with Windows 2000) and became the baseline release of ADO up until today. ADO 2.5 was pretty much feature-complete, consisting of not only ADO itself but also ADOX, ADO MD, and JRO (a Jet supplement to ADO).
Since ADO 2.5 there have been a number of refinements and some important minor features, but basically ADO 2.5 is the core level of functionality. Nothing earlier is discussed much anymore. ADO History.
One major advantage of ADO for relational database access was an escape from the non-performant world of ODBC, an ancient Microsoft low level data access technology. This was replaced by more the powerful and versatile OLE DB Provider approach, which can use more efficient and more flexible client to database server communication and is not limited to relational datastores.
There is an adapter layer Provider called MSDASQL and it is the default Provider. It is there as a shim between ADO and old-style ODBC drivers for compatibility.
The only people who should be using DAO are probably those still migrating VB5 programs to VB6 and those supporting VB6 programs still bound to the old technology. MS Access 2007 breathed some new life into DAO for VBA programs, but as far as I know this only applies to VBA hosted in Access 2007.
VB6 was a transitional release of Visual Basic. Because of this there are some controls that only work with DAO and others that only work with ADO, and a number of controls that can work with either for simple data binding.
We never did get a real VB7, VB8, etc. that would most likely have phased out internal support for DAO entirely. For VB6 programming DAO may remain viable if care is observed (try to use DAO 3.6, the final release circa 1999). There are some issues with running VB6 DAO programs on WinXP64 and Vista64. It may even be impossible, but you might get the 32-bit DAO 3.6 to install and run under WOW64 on those OSs.
DAO is pretty much limited to working with Jet MDBs and perhaps with ACE ACCDBs (Access 2007) if you install the necessary Office 2007 components. DAO does allow a sort of limited access to ODBC "pass through" tables to reach other relational databases too.
RDO is pretty much dead.
ADO still does not offer 100% of the functionality that DAO provides for Jet MDBs, but the gap is pretty narrow. ADO can also be used to do things never imagined with DAO.
The controversy over DAO vs. ADO continues to this day, more than 10 years after VB6 was released.
-
1
- #4
In general DAO goes much faster than ADO if you are just using a Jet MSAccess database and the SQL it supports, but if you want to use other databases use ADO.
I did a test recently and DOA goes at least 5 times faster in filling a datagrid connected to a MSAccess table.
I always have problems using the ADODC control so I only connect the grid to the table in code.
Sometimes if you change too many cells in a datagrid at once you get "multiple step errors"
For reliability I use text entry boxes and save to the database in a dynaset rather than entering in the table.
I did a test recently and DOA goes at least 5 times faster in filling a datagrid connected to a MSAccess table.
I always have problems using the ADODC control so I only connect the grid to the table in code.
Sometimes if you change too many cells in a datagrid at once you get "multiple step errors"
For reliability I use text entry boxes and save to the database in a dynaset rather than entering in the table.
Have a star!
dilettante
MIS
I love it harebrain!
That's what you get when you write something and take breaks in between for something else. If you don't proofread before posting you can "pretty much" look silly.
That's what you get when you write something and take breaks in between for something else. If you don't proofread before posting you can "pretty much" look silly.
- Status
Similar threads
- Locked
- Question