ado vs.dao

[Guest]

I'm sort of an oldie Access guy .. who hasn't touched Access since '97. What
is the benefit of using ADO in place of the older DAO recordsets??? DAO
seems to be much more straight forward.

 

[Rick Brandt]

I'm sort of an oldie Access guy .. who hasn't touched Access since
'97. What is the benefit of using ADO in place of the older DAO
recordsets??? DAO seems to be much more straight forward.

Against a Jet (mdb) database DAO is better and faster. ADO's only advantages
are when used against other engines. I have yet to write a single line of ADO
code.

 

[Guest]

That's what I was hoping to hear .. but in my case I do have some linkage to
MS SQL Server .. which was usually done via ODBC. My performance with DAO
and SQL Server has been adequate. Does ADO really outshine DAO in this case?
and in what way? (e.g. performance, reliability, all, both ..)

thanx!

 

[Rick Brandt]

That's what I was hoping to hear .. but in my case I do have some
linkage to MS SQL Server .. which was usually done via ODBC. My
performance with DAO and SQL Server has been adequate. Does ADO
really outshine DAO in this case? and in what way? (e.g. performance,
reliability, all, both ..)

I couldn't say, but I doubt that any advantages would be noticeable to a
user. You are eliminating a "layer" if you use ADO directly against the
server for recordset stuff in code. On modern hardware you are likely
talking about differences measured with lots of decimal places.

 

[Paul Overway]

I don't think there are any advantages at all in respect to performance...in
fact it may be marginally worse. With ADO, you're adding an additional API
layer for any database engine. The advantage in my mind is being able to
use the same code (or nearly the same) to connect to various database
engines...with the exception of Jet because SQL syntax is different and not
strictly ANSI. So, if you're programming against a Jet database, ADO has no
advantage because you'd have to re-write no matter what, if you moved to
another database engine. Whereas, if your program is written using ADO
against a SQL Server database, there is a good chance you wouldn't need to
make any changes to go against an Oracle, DB2, whatever database.

 

[Guest]

Well thanx rick/paul .. and for those who are following this thread .. I'm
sticking with DAO!

 

[Doug Bell]

Just don't try to append an additional field of Type Decimal!

DAO is an older technology and it seems that it is not being updated.

You can use DAO on connections to other databases (other than MDBs) it works
through the ODBC Drivers.

Again ODBC is an older technology and may not get the updates to support new
DB features.

You should decide wether your application is going to evolve through new
versions and new technologies or if it has a relatively fixed life.


Doug

 

[Guest]

Paul ..
Thanx for the advice .. this app is suppose to be a working prototype (isn't
that was Access is all about) ... so if they like it .. it will be rewritten
... of course .. how many times has a prototype just lingured on into
production.

-bob

 

[Brendan Reynolds]

'Classic' ADO is not being further developed either, and ADO.NET has little
more in common with 'classic' ADO than three letters in it's name. DAO and
'classic' ADO are *both* 'older' technologies now.