Re: ADO vs DAO

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Val Mazur (group51a_at_hotmail.com)
Date: 09/23/04


Date: Wed, 22 Sep 2004 22:53:02 -0400

Hi,

DAO was designed for Access and uses all the advantages of it. ado was
designed to work with any database, which has OLEDB provider and was not
oriented to target any specific DB.
Actually ADO does not add any additional layer if you use it correctly. It
add it in a case if you use DSN or connection string with ODBC driver. In
this case it uses OLEDB for ODBC in between ADO and ODBC driver. It happens
because ADO has to use OLEDB provider and does not work with ODBC directly.
Using DSN-less connection string with OLEDB provider (Jet OLEDB 4.0 in your
case) will speedup application, but not much. My personal opinion is that if
you decided to migrate, then migrate to ADO with SQL Server. MSDE, which is
a light version of SQL Server, is free and has same functionality as SQL
Server with some small limitations

Next links will help you to during migrating from DAO to ADO

http://support.microsoft.com/default.aspx?scid=kb;en-us;225048&Product=ado

http://support.microsoft.com/default.aspx?scid=kb;en-us;240434

http://support.microsoft.com/default.aspx?scid=kb;en-us;303528

-- 
Val Mazur
Microsoft MVP
"Saga" <antiSpam@somewhere.com> wrote in message 
news:uH1ATwOoEHA.3760@TK2MSFTNGP12.phx.gbl...
>
> How about for client/server environment, like SQL Server?
>
> Would ADO be faster than DAO for this?
> Assuming a DSN-less connection.
>
> I have read that DAO may be better for Access dbs, but ADO
> is better for everything else, is this an urban myth? Or am I well
> informed? ;-)
>
> Thanks
> Saga
>
> "Richard J" <RichardJ@discussions.microsoft.com> wrote in message
> news:1992A806-E78E-49C8-9B10-F90D47CDDD1A@microsoft.com...
>> Welcome to the wonderful world of ADO.
>>
>> Without going into a long boring discussion, ADO adds extra layers of
>> communication protocol to the mix that DAO does not have.
>>
>> In the grand scheme of things, DAO communicates from much closer to
> the
>> database than does ADO.
>>
>> I feel sure someone else will further contribute to this thread with a
> more
>> technical dissertation on the differences, but that is how I view the
>> differences and it works good enough for me. =)
>>
>> Richard
>>
>>
>> "Lou" wrote:
>>
>> > I have an app I just changed fro using DAO to ADO and now its
>> > 10 times slower.
>> > I run both on the same machine with the same qry.
>> > Whats going on here?
>> >
>> > The DAO is instant but the ADO using a DSN(Microsoft access)
>> > is VERY slow in populting. They both use the MSDataGrid and both
>> > use a datacontrol.
>> >
>> > -Lou
>> >
>> >
>> >
>
> 


Relevant Pages

  • Re: Text of Startup Option Application Title
    ... This is a quote from Mary Chipman, SQL Server MVP, ex-Access MVP, and author ... DAO was designed, customized, and tweaked specifically for the Jet ... ADO was designed as a general-purpose data access wrapper around OLE ...
    (microsoft.public.access.formscoding)
  • Re: DAO vs ADO
    ... ADO ... > extra overhead retrieving metadata from the server for each query. ... > but I feel DAO is not as unsuitable as is often assumed. ... and ADO when working with SQL Server data. ...
    (microsoft.public.access.conversion)
  • Re: Connecting to a SQL Server 2005 using VBA and ADO
    ... dao should work just fine.... ... the above example when using sql server, or a plan Jane un-split database, ... I would not use findfirst even when not using sql server unless the data set ... Microsoft since they now seem to be favoring ADO. ...
    (microsoft.public.access.formscoding)
  • Re: DAO vs ADO
    ... The best rule of thumb to go by is: use DAO when working with local ... Access/Jet objects, and ADO when working with SQL Server data. ...
    (microsoft.public.access.conversion)
  • Re: DAO vs ADO
    ... The best rule of thumb to go by is: use DAO when working with local ... Access/Jet objects, and ADO when working with SQL Server data. ...
    (microsoft.public.access.adp.sqlserver)