DAO vs ADO

[Alan Welsford]

ADO Code 66 Seconds

Set dcndb = New ADODB.Connectio n
dcndb.Provider = "Microsoft.Jet. OLEDB.4.0"
dcndb.Connectio nString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOn ly, adLockReadOnly

DAO Code 20 Seconds

Set rDb = DBEngine.Worksp aces(0).OpenDat abase(dtbs$)
Set rsUsers = rDb.OpenRecords et(Sql$)

*** Sent via Developersdex http://www.developersdex.com ***

[=?Utf-8?B?TWljaGVsIFBvc3NldGggW01DUF0=?=]

DAO is specially optimized for ACCESS ( Native )

ADO is just a uniform way of acessing datasources through a provider
so they can`t be compared in this way

And for .Net they are both Obsolete so irrelevant ( DAO was / is even
obsolete for VB6 )

As we are here in microsoft.publi c.dotnet , we do it now the recomended way
import all data to a SQL 2005 MDF with SMS , now create T-SQL query`s , and
now analyze this query in the database engine tuning advisor , apply al
recomendations , now run this query from your VB.Net application ( with the
sql native client provider )

what do you see now ?

You wil probably see that the access database performance is blown away and
we ar not even at max , cause we could also create SP`s , indexed views ,
create functions etc etc to do some final tuning , however this requires
skills that most VB proggers do not posess

regards

Michel


"Alan Welsford" wrote:

ADO Code 66 Seconds

Set dcndb = New ADODB.Connectio n
dcndb.Provider = "Microsoft.Jet. OLEDB.4.0"
dcndb.Connectio nString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOn ly, adLockReadOnly

DAO Code 20 Seconds

Set rDb = DBEngine.Worksp aces(0).OpenDat abase(dtbs$)
Set rsUsers = rDb.OpenRecords et(Sql$)

*** Sent via Developersdex http://www.developersdex.com ***

[Harry Strybos]

"Alan Welsford" <me*****@kingsl ey.co.zawrote in message
news:u8******** ******@TK2MSFTN GP02.phx.gbl...

ADO Code 66 Seconds

Set dcndb = New ADODB.Connectio n
dcndb.Provider = "Microsoft.Jet. OLEDB.4.0"
dcndb.Connectio nString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOn ly, adLockReadOnly

DAO Code 20 Seconds

Set rDb = DBEngine.Worksp aces(0).OpenDat abase(dtbs$)
Set rsUsers = rDb.OpenRecords et(Sql$)

*** Sent via Developersdex http://www.developersdex.com ***

Well, the 66 seconds for ADO does seem an inordinate time as does 20 seconds
for DAO, however, the query may be designed to be resource intensive.

DAO has always far outperformed ADO (ADO.Net appears to have bridged that
gap to some extent). It should be noted that ADO does have a higher overhead
given the added functionallity it exposes. Having said that, DAO does
perform beautifully and still exposes enough methods to please most. Just to
get a new identity value in DAO leaves ADO for dead.

If you want to use Access as a back end, DAO is your man. This statement may
be inappropriate given the following:

1. Have not tested how DAO plays with Access 2007
2. Given the massive changes MS have made to VB, DAO may not work at some
later date. Our tests with Vista show DAO is still fine there.
3. DAO can still exhibit some data instability, althought this seems to
be a rare occurrence.

Just by coincidence, I am currently finishing a VB6/DAO project for a
friend. While I really love the power of VB.Net, the VB6/DAO combination is
still really cool for a quick rollout.

Cheers

Harry

[rdrunner]

"Michel Posseth [MCP]" <Mi************ **@discussions. microsoft.comwr ote in
message news:C5******** *************** ***********@mic rosoft.com...

wait !!! before i start a flame war :-)

when i reread the below line i thought it might be interpreted the wrong
way

>however this requires
skills that most VB proggers do not posess

With this line i actually mean that not all VB ( or C# , J# etc etc )
coders have enough knowledge of SQL server to perform these tasks . That`s
why we have Dba`s .

regards

I think every Programmer should be aware of what he does to a DB. I think
this is a skill essential to developing "big" applications. I have seen
VB/C#/... Code that made me "cry" several times already and i can attest
that there are many out there who are not even "helped" by Moores law...

Also... a querry that runs over 20 seconds is something i dont "like" Its to
slow no matter what tecnology you are using ;)

[Cor Ligthert [MVP]]

Michel,

Do you mean that this will only work in China.

To most proggers even the normallization rules are new chinese

:-)

Cor

[aaron.kempf]

I disagree with your analysis of DAO vs ADO.

for starters, MDB is a DEAD FORMAT, anyone that uses it anywhere should
be fired and then spit upon.

and try comparing that to an Access Data Project and ADO

we don't have DBAs; you _ARE_ the DBA

if you don't know enoug about SQL to build a database from scratch then
you shouldn't be a programmer

-Aaron

Michel wrote:

wait !!! before i start a flame war :-)

when i reread the below line i thought it might be interpreted the wrong way

however this requires
skills that most VB proggers do not posess

With this line i actually mean that not all VB ( or C# , J# etc etc )
coders have enough knowledge of SQL server to perform these tasks . That`s
why we have Dba`s .

regards

Michel



"Michel Posseth [MCP]" wrote:

DAO is specially optimized for ACCESS ( Native )

ADO is just a uniform way of acessing datasources through a provider
so they can`t be compared in this way

And for .Net they are both Obsolete so irrelevant ( DAO was / is even
obsolete for VB6 )

As we are here in microsoft.publi c.dotnet , we do it now the recomended way
import all data to a SQL 2005 MDF with SMS , now create T-SQL query`s , and
now analyze this query in the database engine tuning advisor , apply al
recomendations , now run this query from your VB.Net application ( with the
sql native client provider )

what do you see now ?

You wil probably see that the access database performance is blown away and
we ar not even at max , cause we could also create SP`s , indexed views ,
create functions etc etc to do some final tuning , however this requires
skills that most VB proggers do not posess

regards

Michel


"Alan Welsford" wrote:

ADO Code 66 Seconds
>
Set dcndb = New ADODB.Connectio n
dcndb.Provider = "Microsoft.Jet. OLEDB.4.0"
dcndb.Connectio nString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOn ly, adLockReadOnly
>
DAO Code 20 Seconds
>
Set rDb = DBEngine.Worksp aces(0).OpenDat abase(dtbs$)
Set rsUsers = rDb.OpenRecords et(Sql$)
>
>
>
*** Sent via Developersdex http://www.developersdex.com ***
>

[aaron.kempf]

DAO isn't included in WIndows XP, Office 2000 or Office 2002

get a fucking clue kids

DAO has been obsolete for a decade
it's _NEVER_ been faster

-Aaron
Harry Strybos wrote:

"Alan Welsford" <me*****@kingsl ey.co.zawrote in message
news:u8******** ******@TK2MSFTN GP02.phx.gbl...

ADO Code 66 Seconds

Set dcndb = New ADODB.Connectio n
dcndb.Provider = "Microsoft.Jet. OLEDB.4.0"
dcndb.Connectio nString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOn ly, adLockReadOnly

DAO Code 20 Seconds

Set rDb = DBEngine.Worksp aces(0).OpenDat abase(dtbs$)
Set rsUsers = rDb.OpenRecords et(Sql$)

*** Sent via Developersdex http://www.developersdex.com ***

Well, the 66 seconds for ADO does seem an inordinate time as does 20 seconds
for DAO, however, the query may be designed to be resource intensive.

DAO has always far outperformed ADO (ADO.Net appears to have bridged that
gap to some extent). It should be noted that ADO does have a higher overhead
given the added functionallity it exposes. Having said that, DAO does
perform beautifully and still exposes enough methods to please most. Just to
get a new identity value in DAO leaves ADO for dead.

If you want to use Access as a back end, DAO is your man. This statement may
be inappropriate given the following:

1. Have not tested how DAO plays with Access 2007
2. Given the massive changes MS have made to VB, DAO may not work at some
later date. Our tests with Vista show DAO is still fine there.
3. DAO can still exhibit some data instability, althought this seems to
be a rare occurrence.

Just by coincidence, I am currently finishing a VB6/DAO project for a
friend. While I really love the power of VB.Net, the VB6/DAO combination is
still really cool for a quick rollout.

Cheers

Harry

[Franck]

aa*********@gma il.com wrote:

DAO isn't included in WIndows XP, Office 2000 or Office 2002

get a fucking clue kids

DAO has been obsolete for a decade
it's _NEVER_ been faster

-Aaron

DAO was always faster than ADO for Access DB. But since the new ADO.Net
there is people saying it's faster some say it's equivalent.

[aaron.kempf]

you're so fucking full of shit dude

DAO was never faster ONCE than ADO

-Aaron

Franck wrote:

aa*********@gma il.com wrote:

DAO isn't included in WIndows XP, Office 2000 or Office 2002

get a fucking clue kids

DAO has been obsolete for a decade
it's _NEVER_ been faster

-Aaron

DAO was always faster than ADO for Access DB. But since the new ADO.Net
there is people saying it's faster some say it's equivalent.

[Franck]

aa*********@gma il.com wrote:

you're so fucking full of shit dude

DAO was never faster ONCE than ADO

I tried few query :
at 1241 record output DAO is 4 sec faster than ADO
at 11635 record output DAO is 17 sec faster than ADO

DAO ADO jet.4.0 in access

so your comment doesnt apply to my case, i was always faster than ADO
for me and it's still faster, maybe depend on your opinion that is
wrong and youll keep stick to it because i know you are closed minded