Re: DAO vs ADO

From: Joe Fallon (jfallon1_at_nospamtwcny.rr.com)
Date: 08/08/04 

Date: Sun, 8 Aug 2004 17:52:02 -0400

Steve,
Very interesting post.
I think your last statement is an excellent prediction.
I am also betting that MS is working hard on developing some sort of
Access.Net version.
(I do not have any inside info on this topic....) 

-- 
Joe Fallon
Access MVP
"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:degah01rgi5volbm3qka0djiej42hthaea@4ax.com...
> I believe it is not a universal truth that DAO/JET is less efficient than
ADO
> for querying server data.  In fact, if you're not knowledgeable about all
the
> details of ADO operation and careful in implementation, ADO can incur a
lot of
> extra overhead retrieving metadata from the server for each query.  Since
PCs
> are so fast these days, an extra layer of abstraction on the client, more
or
> less, is unlikely to be the bottleneck in a transaction that communicates
> across a network, and then with a data store on a disk drive.
>
> I'm not actually saying DAO is preferable to ADO for accessing server
data,
> but I feel DAO is not as unsuitable as is often assumed.  I used it
> successfully with Access 97 C/S solutions for years before there was an
ADO,
> and that was on what would now be considered antique hardware.  Also, I
still
> find that the tried and true Access MDB/DAO combination is much more
stable
> and predictable than ADP/ADO (or MDB/ADO which is an odd hybrid), so when
> Access is the front-end, I've learned to stick mostly to DAO (except when
I
> want parameterized server SP calls or disconnected recordsets - and not
with
> forms) regardless of the back-end.  This may change later if Microsoft
> improves the ADP/ADO technology, but I'm thinking it's more likely that a
> better Access.NET solution will arise first, and ADPs will never really
take
> off.
>
> On Sat, 07 Aug 2004 10:44:30 -0400, Mary Chipman
<mchip@online.microsoft.com>
> wrote:
>
> >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. In the
> >case of DSN-less links, you are working with local Jet QueryDef
> >objects. The links contain only connection info and not the actual
> >tables, which makes DAO a good choice. If you were to create a
> >recordset in code, you'd want to use ADO since it would be going
> >against SQL Server to retrieve the data. Using DAO in this case would
> >add additional overhead by loading Jet, making it very inefficient.
> >FWIW, in a linked table app it is far more efficient to work with
> >pass-through queries to execute stored procedures and the like, which
> >you can also manipulate easily by using DAO to set the connection and
> >.SQL properties.
> >
> >--Mary
> >Microsoft Access Developer's Guide to SQL Server
> >http://www.amazon.com/exec/obidos/ASIN/0672319446
> >
> >On Fri, 6 Aug 2004 14:56:50 -0400, "Sirocco" <NB2002@arczip.com>
> >wrote:
> >
> >>I found an article that contains DAO code to create a DSN-less link to
SQL
> >>Server.   This is exciting to me because I thought ADO must be used when
the
> >>tables were on a SQL Server, and have been somewhat anxious about
converting
> >>my existing DAO to ADO, and have even started using ADO in some of my
new
> >>coding projects.     Granted I'll have to re-code my existing VB when I
> >>transfer my tables to a SQL back end, in particular to define my data
> >>source, but can I in fact use DAO, as this article suggests?
> >>
> >>Also, generally, when using a SQL back end, when MUST I use ADO and when
can
> >>I just use my existing DAO?
> >>
> >>Many thanks in advance.
> >>
>

Relevant Pages

  • Re: SQL Server extremely slow
    ... terms of what is meant by a dis-connected ado recordset. ... table in a mdb file could be considered disconnected from the server ... Well, ok, but keep in mind the disk drive is on sql server! ... 10 reocrds from the server via odbc does not produce more ...
    (comp.databases.ms-access)
  • 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: CHANGING from DAO to RDO
    ... To boost the speed we use Terminal Server 2003 and it definetly helps on the fact that we get less corruption, but certain queries take awhile and we want to add more users. ... I don't know _where_ you got the idea that ADO and RDO were the only methods to access SQL Server. ... In fact, I have never heard of anyone using RDO with an Access database, only, in the past, with the separate VB product. ... The VB crowd abandoned it for ADO with SQL Server, even though they, too, could use DAO and, for them too, DAO was simpler and easier. ...
    (microsoft.public.access.modulesdaovba)
  • 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: Error -2147168227 Cannot create new transaction because capacity was exceeded.
    ... OLEDB provider for SQL Server. ... > I have been unable to find info in the Knowledge base, ADO or SQL Server ... > ADO driver generates the error. ...
    (microsoft.public.data.ado)