Re: Why not use DAO?
- From: "Scott M." <s-mar@xxxxxxxxxxxxx>
- Date: Sun, 24 Dec 2006 09:44:54 -0500
Hi Michel,
There were 2 things about your fist message that troubled me and you've
resolved one of them (putting some reasoning behind your blanket
statements). But I still have to say that you are still confusing apples
and pears or more like apples and watermelons.
You have been refering to DAO vs. ADO when these two things (in the context
of this discussion) are very different. DAO is a database connection
provider/interface used by various controls, but DAO is not the controls
themselves. ADO is a set of objects that provide an API to a database that
you must have ALREADY used a provider to get to. ADO doesn't imply the
underlying provider (as I'm sure you know you can use several different
providers to get to Access and still be using ADO). Did you mean to say OLE
DB Providers instead of ADO because DAO and OLE DB Providers are apples to
apples and DAO compared to ADO is apples to watermelons.
Additionally, it still doesn't make sense to talk about data containers
(DataAdapters, TableAdapters, DataReaders) here since that leads to
confusion between data providers and data API's (which you yourself have
already confused when comparing DAO and ADO). And data containers don't
have anything to do with the speed of the communication via the
driver/provider, which was the whole point of the post. Your recordset,
tableadapter, datareader comments are simply comparisons of ADO.NET's
connected vs. disconnected objects, but talking about the performance of
these objects doesn't speak to the speed of the underlying provider.
In the end, I agree with you about which road to take (as I stated in my
first message) and for many of the same reasons, but I felt compelled to
play devil's advocate here because your first post began with more of a
sermen (just don't use it because I & MS said so), than any facts and both
your posts get off-topic by DAO and ADO and talking about data APIs and
contaners, which don't have anything to do with the OP question.
Happy holidays.
- Scott
"Michel Posseth [MCP]" <MSDN@xxxxxxxxxxx> wrote in message
news:eXY5Ct0JHHA.2456@xxxxxxxxxxxxxxxxxxxxxxx
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
"Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx> schreef in bericht
news:%2348G6yyJHHA.1064@xxxxxxxxxxxxxxxxxxxxxxx
Scott,
What is the sense of this message from you bad humeur,
Michael,
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.
I completely disagree with you I see Michael as one of the most important
contributers to this newsgroup.
Not to disapoint you, you are as well in those. However I don't see any
sense of the need of the message from you. I 100% agree with what Michael
has written about this.
Cor
.
- Follow-Ups:
- Re: Why not use DAO?
- From: Michel Posseth [MCP]
- Re: Why not use DAO?
- References:
- Why not use DAO?
- From: TC
- Re: Why not use DAO?
- From: Cor Ligthert [MVP]
- Re: Why not use DAO?
- From: Michel Posseth [MCP]
- Re: Why not use DAO?
- From: Scott M.
- Re: Why not use DAO?
- From: Cor Ligthert [MVP]
- Re: Why not use DAO?
- From: Michel Posseth [MCP]
- Why not use DAO?
- Prev by Date: Re: How to determine if e-mail was sent OK
- Next by Date: Re: Newbie question
- Previous by thread: Re: Why not use DAO?
- Next by thread: Re: Why not use DAO?
- Index(es):
Relevant Pages
|
