Re: DAO vs ADO

Tech-Archive recommends: Speed Up your PC by fixing your registry

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" <men1720@xxxxxxxxxxxxxx> wrote in message
news:u82HNxwLHHA.3668@xxxxxxxxxxxxxxxxxxxxxxx
ADO Code 66 Seconds

Set dcndb = New ADODB.Connection
dcndb.Provider = "Microsoft.Jet.OLEDB.4.0"
dcndb.ConnectionString = "Data Source=" + dtbs$
dcndb.Open
Set rsUsers = New ADODB.Recordset
rsUsers.Open Sql$, dcndb, adOpenForwardOnly, adLockReadOnly

DAO Code 20 Seconds

Set rDb = DBEngine.Workspaces(0).OpenDatabase(dtbs$)
Set rsUsers = rDb.OpenRecordset(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

.

Quantcast