Difference between DAO,ADO and ODBC
Srinivas
what are the major differences between DAO,ADO and ODBC?
what are the advantages over another?
Thanks in advance
Regards
Srini
William (Bill) Vaughn
access data stored in a database.
DAO is designed to access JET/Access databases (only). It includes a great
deal of flexibility to deal with DDL/DML issues and manage the database
schema.
ODBC is an API interface designed to access any relational database that
supports an ODBC driver. DAO uses ODBC behind the scenes to access
relational databases (albeit not very efficiently).
ADO (COM-based "classic") is a VB-accessible route to the OLE DB data access
interface which uses "providers" (like ODBC drivers) to access data in
relational and non-relational databases. ADO is generally accepted as the
defacto standard way to access data from VB, C++ and Office applications.
ADO's biggest problem is COM and DLL hell issues.
ADO.NET is an entirely new data access interface built into the .NET
Framework. It bears little resemblance to ADO classic. It is COM-less and
shares none of the DLL hell issues with it's predecessor.
I discuss each of these in my books.
hth
--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Srinivas" <sriniv...@macrosolindia.com> wrote in message
news:220701c378f1$6fcd68d0$a601...@phx.gbl...
Rich
classes while ODBC is a standard for "data providers".
You use either DAO or ADO with ODBC. DAO is supposed to
be optimized for ODBC while ADO is optimized to OLD DB,
which is another data provider. (I'm pretty sure you can
use DAO with OLE DB as well.)
DAO is a predecessor to ADO - ODBC is a predecessor to
OLE DB.
Microsoft recommends ADO/OLE DB for new development but
that converting DAO code to ADO may not be worthwhile in
terms of performance improvement, etc.
HTH
>.
>
rlfine
"Rich" <richard...@baesystems.com> wrote in message
news:04c701c3798b$eb959650$a401...@phx.gbl...
> DAO and ADO are both client-side "data consumer" object
> classes while ODBC is a standard for "data providers".
>
See William Vaughn's response -- these three technologies are all client
side programming interfaces. ADO is but a set of wrapper interfaces,
implementing the IDispatch interface, and are written to OLEDB. If you
have an OLEDB provider (and if that provider has the requisite
interfaces implemented), you can access the provider using ADO.
ODBC is suitable only for querying and accessing recordset structures.
If your data can not be expressed in these terms, ODBC is not a good
choice. OLEDB addresses these issues.
> You use either DAO or ADO with ODBC. DAO is supposed to
> be optimized for ODBC while ADO is optimized to OLD DB,
> which is another data provider. (I'm pretty sure you can
> use DAO with OLE DB as well.)
>
DAO has nothing to do with ODBC -- DAO is the MSFT proprietary data
access for the Jet Database Engine. It is not even correct to say that
DAO is optimized for Jet - becausae Jet is all that DAO works with.
>
> DAO is a predecessor to ADO - ODBC is a predecessor to
> OLE DB.
>
>
> Microsoft recommends ADO/OLE DB for new development
Not any more -- MSFT is all .Net all day now days.....
> but
> that converting DAO code to ADO may not be worthwhile in
> terms of performance improvement, etc.
>
An list of "Good reasons to port FROM DAO" would certainly include a
need to interface to something other than the Jet Database Engine.
While I suspect MSFT will do nothing to cause DAO to stop working, I
suspect they will do little to keep it working -- e.g. don't expect to
see any Jet Database Engine support in any 64 bit environments. I say
again - don't expect to see Jet Database Engine in any 64 bit
environment. There is strong evidence that MSFT Access will have MSDE
as the database on 64 bit platforms, and soon after that, it will be ALL
MSDE, and no more Jet Engine.
roy fine
Rich
be correct on some theoretical level. However, in our
shop we support at least one application - that I know of -
that incorporates the "Microsoft DAO 2.5 Object Library"
(DAO2516.DLL) to access an Oracle database via a (16-bit)
ODBC driver that was distributed by Intersolv.
Far be it from me to assert that this particular
combination of technologies would be a wise choice for any
current development. But this particlar application was
released into production in 1997 and, guess what, it
works! It is also my understanding that was quite a
common practice until the introduction of RDO.
This may have something to do with the fact that our
customer pays us to deliver effective, working results,
even when a given approach may not fully corroborate some
theoretical conclusion that may be drawn from parsing and
mincing terminology from books and articles.
But, while we're at it, take a look at the MSDN Article
entitled "Accessing Data with DAO"
(http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/vsentpro/html/veconaccessingdatawithdao.asp)
The article lists three categories of databases that are
accessible with DAO/Jet: Native Microsoft Jet Databases,
External Databases, and ODBC databases. ODBC databases
are defined as "relational databases that conform to the
ODBC standard, such as Microsoft SQL Server".
Or how 'bout this passage from DAO-related documentation
in MSDN: "The third type of database format that is
accessible through DAO is the Open Database Connectivity
(ODBC) data source. ODBC data sources, such as Microsoft
SQL ServerT versions 4.2 and later, require an ODBC
driver."
Believe what you like.
>.
>
William (Bill) Vaughn
cannot access OLE DB data sources at all. It was originally designed to be a
programmatic interface to JET--ODBC support was added as an afterthought.
DAO is an adequate to good interface to JET. However, DAO is not a good way
to access serious relational databases and while it can be used to do so, it
ignores many highly productive features and much of the power of serious
DBMS engines. Yes, there are applications that work today with DAO but these
applications do not scale and are often replaced with ADO or ADO.NET
applications when they fail to compete with more efficient applications that
are easier to write and support. Part of the issue is the lack of support
for DAO in the development community although there are lots of books
available on DAO--in the 2nd-hand book stores. Look under "obsolete" or
"ancient history". ;)
--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Rich" <richard...@baesystems.com> wrote in message
news:011701c37b9a$fcde8f50$a101...@phx.gbl...