First of all Cor thank you for your support in this mather it is clear to
me that you completely read it and interpreted it in the right way
Second :
Scott ...
You :
What is not in doubt is that DAO has historically been the fastest
interface for working with JET databases. Saying otherwise is just not
true
Me:
DAO is in most situations faster on a Access database ,,, there is no
discussion about that ( DAO was also faster as classic ADO )
To be more clear :
I said most situations cause if you do data manipulation on different
databases ACCESS to SQL for instance ADO is the bether and faster choice
DAO is especially made and optimized for ACCESS database ADO is a more
universal provider so ofcourse DAO wil outperform ADO in most situations
on ACCESS databases
Cause in my experience i actually found situations were ADO was faster due
to its superior caching mechanism , in my previous employment i worked 8
years for a company who deployed there applications with ACCESS 97 / 2000
databases and i did a lot of speed comparisation between all sorts of
databases and providers that are availlable , and sometimes i discovered
some surprising results when you actually do multiple selects on hughe
resultsets ADO will be faster on the second select , in our situation ADO
became interesting due to this fact as we wrote catalog software where we
actually queryed with hughe resultsets spanned on multiple databases (
multiple access database because of the size limit in this occasion ) and
did these query`s more than once ( actually a few dozen during runtime of
the program ) .
You
I ignored most of your message because you are not providing any real
infromation. Simply saying "don't use this because the powers that be say
it's obsolete" doesn't quite cut it.
And
Having said all of this, I personally use the OLE DB Provider for JET when
using Access databases because I prefer the availability of the provider.
But, let's be clear...whatever provider/driver you use, the data can be
loaded up into whatever container you wish.
Me
Let me be the one that tells you "don`t use DAO" and with that i mean stay
away of it there is only one exception in my opinion when you should still
use it
"You are a VB6 programmer , and need to maintain a prog written with DAO "
In VB.Net ( all versions ) it is a definite no go
Why ?? well because it is absolutely undeniable obsolete
To be more clear :
Well actually i wouldn`t know how i could be more clearer about this but i
try to convince you , DAO was already declared obsolete by MS on the VB6
platform so using it now in VB.Net would be a valid way of coding ? , well i
would laugh the person away who would come with this sort of coding to my
desk
About the availlability of the provider ,, funny as far as i know mdac 2.5
is the latest version that actually included Jet Oledb drivers so i wish
you lots of luck on fresh installed systems , in the company i previously
mentioned i was also responsible for the deploy packaging and XP doesn`t
like Mdac 2.5 as it is standard equiped with a newer version so you have
to find the seperate installation package ( that i now can`t even find on
the MS site , but it sure was there a few years ago ) or have as dependancy
of your app that an office product should be installed .
You
Also, speaking of apples and pears, why are you talking about TableAdapters
and recordsets, when we are talikng about data access and not data
storage/manipulation?
Me
By the way a standard ADO recordset with a firehose cursor is also much
faster as a typical ADO.Net table adapter aproach however if you use a
datareader they perform equall ADO.Net might even be faster on SQL server
cause it uses a optimized driver so don`t compare pears with apples
To be more clear :
Well ..... i just wanted to make clear that you should compare these on
there equivalant , a firehose cursor opened recordset should be compared to
a datareader
and a updatable recordset should be compared to a table adapter
This brings me to the following statement , and i must say that i was
convinced about this by Bill Vaughn in a few discussions i had in the past
with him while i was also sticking to Access .
That if you use a MDF in your projects , wich is nowadays so easy to do and
to deploy etc etc you wil blast away the old perfomance of Access , as far
as i know the now recomended way of MS is to use this database in
combination with .Net there is now actually no reasson to stick with Access
The support for Access is fading away , why isn`t there a 64 bits provider ?
, why isn`t ADOX ported to .Net ?
Well i hope i hope this makes things clearer
regards
And merry christmas to anyone who reads this
Michel Posseth
