compare ADO control to DAO

[petevick]

I've recently completed a project in which I have used ADO controls extensivly. I'm just wondering if there is any benifit in using DAO, ie, does DAO process databases faster then ADO controls, is the complied code any smaller with DAO. Anyone got any thoughts?

Pete Vickerstaff - Hedra Software

http://www.hedrasoftware.co.uk

 

[zemp]

The main difference is that DAO is pretty much limited to MS Access and ADO can be used for almost any database. I have heard that DAO is slightly faster than ADO (with Access of course) but is having to learn to use two sets of data objects (if you ever have to work with something other than Access) worth your time? Of course there is no right or wrong. It is entirely up to you.

Thanks and Good Luck!

zemp

 

[petevick]

Thanks for the input Zemp, it is just an Access DB I'm using, maybe I'll do a few tests....maybe

Pete Vickerstaff - Hedra Software

http://www.hedrasoftware.co.uk

 

[Golom]

Another thought on ADO Vs. DAO with Access is that there is nothing to prevent you using both in a VB project. The syntax is different of course but, if you have speed-sensitive tasks you may find DAO quicker while the bulk of your processing would use ADO to simplify the migration (when and if) to some other DBMS.

 

[petevick]

I am using mainly ADO, but I've used DAO for just one task, it seemed easier to use, I'm just not sure how well DAO will handle some of the more complex SQL statements I have, I guess I'll just have to give it a go.

Pete Vickerstaff - Hedra Software

http://www.hedrasoftware.co.uk

 

[harebrain]

ADO is the more recent technology. Chances are good that learning it and using it will be of greater future value to you.

 

[petevick]

Thats a fair point harebrain. But I'm also guessing that if I dump all the ADO controls from my project in favour of using DAO code, that this will reduce the size of my executable (which has now grown to 2.1MB !!), there should still be a similar amount of code to deal with record access etc, thats my theory anyway.

Pete Vickerstaff - Hedra Software

http://www.hedrasoftware.co.uk

 

[CassandraR]

Hi Pete:

This suggestion may be a bit late, given that your application has been written.

If possible, place all of the database accessing code in a module. One could write a module using only DAO, another module using only ADO, and possibly a third combining the two methodologies. That way one can swap in a module, conduct performance tests (including code size), then try each of the other possiblities to do the comparisons.

Cassie

 

[petevick]

Hi Cassie, no suggestion is ever too late, there are always other projects to implement. I like the idea of a module for DAO stuff, just might use that.
I'm really looking to make the project less ADO component weighty, I've got 'em on just about every form (27 in total), one evem has 11. This is the first DB project I've done, so I don't mind changing all the ADO's to DAO for a future release if I new there would be speed/app size benifits.

Pete Vickerstaff - Hedra Software

http://www.hedrasoftware.co.uk

 

[CassandraR]

Hi Pete:

Personally, I rarely resort to DAO, since I started working with ADO and ADOX. Mind you, I don't deal with very large databases and timing is not a problem. Ease of use and maintainability, for me, outweighs the program timing.

Also, thinking in OOP helps when it comes to VB6 programming. All my registry access functions are in one module. The module rarely changes and has been extensively tested. New project? Just add the module of pre-tested code. I love the concept. Something about not re-inventing the wheel?

Have a great day!
Cassie
;-)