Many will point out that "dao" is the native object model for JET, and thus
the prefer it.
DAO also has some better control of the JET security object model also.
However, really, if you are comfortable with ADO, then I would continue to
use it.
ADO is a newer object model then is DAO, and I find the ADO model a little
bit "cleaner" then the DAO object model. (you don't have to issue a update
to write a record out for example). ADO is also designed as a independent
layer. So, if you later convert your
code to sql server, then that ADO code should be more at home.
And, ADO has built in support for stored procedures etc, so again if sql
server is in the future, it is a good choice.
Is there any difference in Speed?
No, not normally. You are going through a "extra" layer, but it turns out
what you loose in that layer you get back in how well ADO handles the
connection, and also the indexing and finding of things in a reocrdset works
well in ADO. And, ADO does connect well to JET. By well, I mean I seen a few
cases where ADO used indexes better then DAO to JET, which is rather
surprising.
So, substantial performance gains?
No, 99% of the time, no difference.
And, with ADO you got a more open object model.
One big one is the DAO seek command.
dao has the "seek" command, which by the way is faster then anything to grab
data from a table in a loop for a given id each time through the loop. But
then you can't use the "seek" command on sql server tables (and, for linked
tables, you have to open the back end table via code to use seek). And, most
of the time, that loop can be replaced with some sql statement anyway.
But, in a pinch, seek is rather fast, as it is much like the old FoxPro or
dbase days, and you are direct using the engines index, and no sql....
It is blind fast, and you could use it anyway if you needed to.....
I would say you are not missing out here on a general performance issue...
