Re: Fastest record create method with JET 4.0


"Desertphile" <desertphile@xxxxxxxxxxx> wrote in message
news:1158159248.739888.253840@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ralph wrote:
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:uWQiNCz1GHA.1040@xxxxxxxxxxxxxxxxxxxxxxx
As someone else pointed out, DAO code may be written shoddy and
still
do the job. Even with lazy code, DAO ought to be faster at inserting
records into an Access database than ADO, even though Microsoft says
otherwise.

Where do they say that?
I believe Microsoft do acknowledge DAO is faster than ADO for Access
databases
See http://support.microsoft.com/kb/225048/
where you can read what DAO and ADO philosophy.

But frequently programmers use ADO badly so the performance
difference
may
not be that apprecaibly different.

Stephen Howe


Just to be boorish for a moment.

MS has switched its "pronouncements" several times concerning DAO. When
ADO
first appeared, ADO was touted as being the only way to go, and that all
subsquent development of DAO was going to be discontinued. DAO 3.6
slipped
in rather quietly.

While I am not sure MS themselves ever stated "ADO is faster". Many
authors
and insiders certainly did. I believe most of the time it was just an
extra
adjective tacked on without too much thought (and certainly without
testing). After all once you have proclaimed something as prettier,
slicker,
cleaner, simpler, neater, ... What is more natural that to proclaim it
'faster'?

The waters also became cloudier at this time, because OLE DB was also
introduced. Many comparisons were made at the time comparing DAO with
ADO,
with the unfortunate underlying, but understated, actual comparison of
ODBC
with OLE DB. "DAO" always came out the loser. (With one exception DB2)

You make a good point, that ultimately it always comes down to how you
are
using the tool. A common discovery when visiting teams using ADO and
chewing
away on some 'performance' problem, is to examine the connection string
and
learn that they are using ODBC or an outdated provider. <g>

I have the year 2002 MSDN CDs. "Choosing a Data Access Strategy" lists
ADO and RDO as "Very Fast," and says nothing about DAO speed: it says
one may wish to stick with DAO if one has a lot of existing DAO code.

The MSDN article "Data Access Using Data Access Objects (DAO)" states
one of the traits of DAO is "Adequate-to-slow performance." It then
states "Compared to the newer ActiveX Data Objects (ADO) or Remote Data
Objects (RDO) technologies, Data Access Objects (DAO) is a slower, less
capable data access alternative," however I have not known that to be
the case. As you pointed out, the author of that article may have been
making assumptions not based in reality, or perhaps it was true four
years ago with older software.

There are several variables that modify speed, of course. Surely there
must be web pages that show tests that compare various data access
technologies.

When I was collecting data from an AS/400 via ODBC, I used ADO. It was
gawdawful slow because IBM's ODBC driver sucked limes, and the AS/400
would refuse to grant me an adequate slice of CPU time. It was also
transported over IBM Token Ring (shudder). One would hope that IBM has
improved their AS/400 connectivity to client machines.... but one never
knows with IBM. :-)


I couldn't think of any specific references (and too lazy to go look) but I
always got the distinct impression that MS used to pitch ADO as faster. And
with most database it was.

It is interesting that you mentioned the AS/400. We had exactly the same
experience years ago. And discovered that DAO was much faster. I found out
that the client engine for AS/400 is ODBC at heart. We eventually
dramatically improved performance by using what I vaguely remember as a 3rd
party <?> driver. Can't remember the name to save my soul.

It is one of those business critical legacy apps that will never die. I get
a laugh because everytime they change out a project manager or get a new
developer, one of the first things they recommend is using ADO. So every
year we have to come back and tell them to leave the damn thing alone. <g>

-ralph


.

Relevant Pages

  • Re: Knowledge Base Help Not working
    ... Database is a DAO object. ... both Access 2000 and 2002 use ADO. ... Microsoft DAO 3.6 Object Library, ... For example, to ensure that you get a DAO recordset, you'll need to ...
    (microsoft.public.access.formscoding)
  • Re: ADO and the Find method
    ... You cannot compare DAO and ADO. ... database, which has OLEDB provider. ... >>>> Opening of the whole table was not a good design anytime. ...
    (microsoft.public.vb.database.ado)
  • Re: Crosstab query error 3104
    ... Thankfully very few compile errors had to ... I have both DAO & ADO references checked but DAO is higher so it is taking ... Thanks - I inherited the original database & am gradually working through ... then perhaps you've removed the reference to ADO. ...
    (microsoft.public.access.queries)
  • Re: Database variable change from 97 to 2003
    ... Access 2003 has references set to both DAO ... and ADO and, perhaps unfortunately, the ADO reference is set higher in ... use Dim rcd As ADODB.Recordset) ... > modules, however, I get errors on the database variable ...
    (microsoft.public.access.modulesdaovba)
  • Re: Creating tables
    ... Frederico has recommended you to replace the solution with an ADO one. ... DAO is "Data Access Objects". ... direct interface to the database engine and it is being implemented in open ... SQL Server with stored procedures and triggers, ...
    (comp.lang.cobol)