DAO and MS Access

[Ian Bayly]

José

You went to a lot of effort to provide these excellent samples of DAO code, thank you for that.

Could I ask two questions please.
1.  Where can I download the DAO.inc file you include?
2.  Why, when many PB Posts advise against the use of DAO in deference to ADO, did you put the effort into providing these samples of code?

Rightly or wrongly, as long as I can get away with it, I will stick with DAO for speed, reliability and lack of dependencies.

Ian Bayly

[José Roca]

Where can I download the DAO.inc file you include?

It is part of my Windows API Headers: http://www.jose.it-berater.org/smfforum/index.php?board=344.0

Why, when many PB Posts advise against the use of DAO in deference to ADO, did you put the effort into providing these samples of code?

ADO is more suited to work with non-Access databases; DAO is optimized for Access databases. I prefer to use ADO because I don't work with Access databases, excepting for the examples.

EDIT: Notice that these headers are incompatible with the headers provided with the compiler, so if you want to use the later ones, you will need to build your own DAO.INC file using the PB COM Browser or my TypeLib Browser.

[Frederick J. Harris]

For what its worth Ian, I love DAO and MS Access.  I get tired of hearing folks bad mouth them, so I don't bother mentioning them anymore, but I still use them.  I'm a former Visual Basic programmer, and DAO with VB and Access was dynamite.  Basically, what I think was going on there is that since they were both Microsoft technologies, I believe VB's DAO code went 'underneath' ODBC and dealt with Access more or less as an ISAM (Indexed Sequential Access Method) database, rather then through the more cumbersome ODBC driver route.  I don't know - I'm just guessing.  But now I mostly use ODBC direct function calls, but I don't believe its as fast as DAO with VB.