Re: Why not use DAO?
- From: "Michel Posseth [MCP]" <MSDN@xxxxxxxxxxx>
- Date: Sun, 24 Dec 2006 17:04:51 +0100
Well .....
All reall life programmers i know of use the jet oledb 3.5 or 4.0 provider
i.c.w. ADO for ACCESS
Ofcourse i am aware of what you stated however i thought it would be
obvious ( by the way ODBC outperforms OLEDB as long as you do single
selects ) however having to tell all this information could fill a book .
The TS asked "Why not used DAO ?" i gave valid reassons not to use DAO in
..Net ( it is oficially declared Obsolete a long while ago and you are thus
not able to support it to your customers )
As extra i mentioned the stuff regarding classic ADO and ADO.Net and again
i thought it would be obvious in what i mean .. i know a lot of people are
still using classic ADO because of the exact reasson i mentioned .
It could sure be that the TS is falling back to legacy ( pre .Net ) due to
the fact that he believes the older technolgies are perfoming better however
they do absolutely not if you use there counterparts on the .Net platform
( MDB = MDF , a firehose cursor opened recordset should be compared to
a datareader and a updatable recordset should be compared to a table
adapter )
That is what i was trying to do ... i understand now that you misunderstood
my intentions
Well maybe it was a language or cultural thingy , but i hope it is cleared
up now
I don`t know where you are from but i live in the Netherlands with a wife
who is from Southern America this means ( lucky me :-) i have to celebrate
3 christmas evenings and dishes ( 24 christmas SA , 25 NL and 26 NL ) ,
so i have now to get ready before the diners guests arrive
regards
michel
"Scott M." <s-mar@xxxxxxxxxxxxx> schreef in bericht
news:eGOoZn2JHHA.1468@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- 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]
- Re: Why not use DAO?
- From: Scott M.
- Why not use DAO?
- Prev by Date: Re: Determining Column Number from Column Name
- Next by Date: Re: Determining Column Number from Column Name
- Previous by thread: Re: Why not use DAO?
- Next by thread: Re: Why not use DAO?
- Index(es):
Relevant Pages
|
