473,320 Members | 1,982 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Why not use DAO?

TC
I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC

Dec 22 '06 #1
17 1373
Well you just do that :)

I hope that nobody has ever told you "Don't use DAO." but if they did I hope
they really meant "It is recommended that you don't use DAO.", which are two
totally different statements.

I, myself, am surprised that you report such a 'speed' difference but then
"For updates to an .mdb file, it is 4x faster" is a pretty broadbrush
statement.

I, for one would like to see the code you are comparing both for OleDB and
DAO.
"TC" <go*********@yahoo.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...
>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC

Dec 22 '06 #2
TC,

I have an opposite opinion as Stephany, I surely would not go the road from
DAO. Even moreover, I would not go any direction using the Jet Engine for
new applications. We don't know how long it will be on newer OS. Therefore
just go to SQLExpress as is often told in these newsgroups is in my idea a
better approach.

I am with Stephany curious about your code, although it is known that DAO is
slightly quicker than all other that is made after it.

Cor
"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@73g2000cwn.googlegro ups.com...
>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC

Dec 22 '06 #3
Well especially for Stephany ..

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 , i would also not
recomend classic ADO cause it is obsolete because we have ADO.Net
DAO is in most situations faster on a Access database ,,, there is no
discussion about that ( DAO was also faster as classic ADO )

However i would recomend you to use a mdf in your projects , this will blast
away the perfomance of Access and is the bether way as using obsolete
products in your newly to deploy application.

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 :-)
regards

Michel Posseth [MCP]

"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:eu**************@TK2MSFTNGP06.phx.gbl...
TC,

I have an opposite opinion as Stephany, I surely would not go the road
from DAO. Even moreover, I would not go any direction using the Jet Engine
for new applications. We don't know how long it will be on newer OS.
Therefore just go to SQLExpress as is often told in these newsgroups is in
my idea a better approach.

I am with Stephany curious about your code, although it is known that DAO
is slightly quicker than all other that is made after it.

Cor
"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@73g2000cwn.googlegro ups.com...
>>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC


Dec 23 '06 #4
I'll second that!
"Stephany Young" <noone@localhostwrote in message
news:uE*************@TK2MSFTNGP06.phx.gbl...
Well you just do that :)

I hope that nobody has ever told you "Don't use DAO." but if they did I
hope they really meant "It is recommended that you don't use DAO.", which
are two totally different statements.

I, myself, am surprised that you report such a 'speed' difference but then
"For updates to an .mdb file, it is 4x faster" is a pretty broadbrush
statement.

I, for one would like to see the code you are comparing both for OleDB and
DAO.
"TC" <go*********@yahoo.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...
>>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC


Dec 23 '06 #5
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.

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.

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?

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.

"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:e9**************@TK2MSFTNGP04.phx.gbl...
Well especially for Stephany ..

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 , i would also
not recomend classic ADO cause it is obsolete because we have ADO.Net
DAO is in most situations faster on a Access database ,,, there is no
discussion about that ( DAO was also faster as classic ADO )

However i would recomend you to use a mdf in your projects , this will
blast away the perfomance of Access and is the bether way as using
obsolete products in your newly to deploy application.

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 :-)
regards

Michel Posseth [MCP]

"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:eu**************@TK2MSFTNGP06.phx.gbl...
>TC,

I have an opposite opinion as Stephany, I surely would not go the road
from DAO. Even moreover, I would not go any direction using the Jet
Engine for new applications. We don't know how long it will be on newer
OS. Therefore just go to SQLExpress as is often told in these newsgroups
is in my idea a better approach.

I am with Stephany curious about your code, although it is known that DAO
is slightly quicker than all other that is made after it.

Cor
"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@73g2000cwn.googlegr oups.com...
>>>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I've been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I'm not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I'm
posting here just to find out what other experienced NET developers
think about this. Certainly, I'm not the first person to go down this
road, and I'm curious what choices others have made.
-TC



Dec 23 '06 #6
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
Dec 24 '06 #7
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]" <no************@planet.nlschreef in bericht
news:%2****************@TK2MSFTNGP04.phx.gbl...
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


Dec 24 '06 #8
Cor,

I didn't say anything about Michael's status or knowledge. What I did say
was that a good portion of his post had no real basis in fact and was not
relevant to the OP question.

Happy Holidays.

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
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

Dec 24 '06 #9
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]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
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]" <no************@planet.nlschreef in bericht
news:%2****************@TK2MSFTNGP04.phx.gbl...
>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



Dec 24 '06 #10
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-***@nospam.nospamschreef in bericht
news:eG**************@TK2MSFTNGP04.phx.gbl...
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]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
>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]" <no************@planet.nlschreef in bericht
news:%2****************@TK2MSFTNGP04.phx.gbl...
>>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




Dec 24 '06 #11
Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
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

Dec 24 '06 #12
"Cor Ligthert [MVP]" <no************@planet.nlwrote in
news:eu**************@TK2MSFTNGP06.phx.gbl:
I have an opposite opinion as Stephany, I surely would not go the road
from DAO. Even moreover, I would not go any direction using the Jet
Engine for new applications. We don't know how long it will be on
newer OS. Therefore just go to SQLExpress as is often told in these
newsgroups is in my idea a better approach.
I agree - why continue to use Access unless absolutely necessary? MSDE or
SQL Server Express are probably better solutions.

Or even Firebird Embedded.
Dec 24 '06 #13
Hello Robin S.

it is now 3:40 AM the people have just left :-)

To me your opinion sure does mather , cause as i am not a native English
speaker and live in a country where something that is spoken may mean
something totally different when translated direcly to other languages, i
am sometimes confused if it is my style of writing or just the other side
that is missing my point .

So thank you verry much
regards

Michel
"RobinS" <Ro****@NoSpam.yah.noneschreef in bericht
news:KZ******************************@comcast.com. ..
Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
>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


Dec 25 '06 #14
Well, if they stayed that late, it sounds like you had a
good time. Or at least, *they* did! That's a good thing.
I hope there was pie involved. :-D

I understand about the English thing; I can generally understand
what you say, if that makes you feel any better.

Have a merry Christmas!

Robin S.
---------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:O9**************@TK2MSFTNGP03.phx.gbl...
Hello Robin S.

it is now 3:40 AM the people have just left :-)

To me your opinion sure does mather , cause as i am not a native
English speaker and live in a country where something that is spoken
may mean something totally different when translated direcly to other
languages, i am sometimes confused if it is my style of writing or
just the other side that is missing my point .

So thank you verry much
regards

Michel
"RobinS" <Ro****@NoSpam.yah.noneschreef in bericht
news:KZ******************************@comcast.com. ..
>Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
>>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



Dec 25 '06 #15
Michel,

Don't listen to those who say something about your English. Especially Scott
had sent many complaints about my use of English (which can be very bad but
the same is with Dutch when I do it quick). What he does not know that the
status of English in our country is the same as in the USA. It has no
official status. The only difference is probably that percentage wise in
Holland more people can and do speak English than in the USA. And like those
Americans do we have our own dialect if we are speaking or writing quick.

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:O9**************@TK2MSFTNGP03.phx.gbl...
Hello Robin S.

it is now 3:40 AM the people have just left :-)

To me your opinion sure does mather , cause as i am not a native English
speaker and live in a country where something that is spoken may mean
something totally different when translated direcly to other languages, i
am sometimes confused if it is my style of writing or just the other side
that is missing my point .

So thank you verry much
regards

Michel
"RobinS" <Ro****@NoSpam.yah.noneschreef in bericht
news:KZ******************************@comcast.com. ..
>Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
>>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



Dec 25 '06 #16
Cor, the only thing I've ever said about your English is that, at times, I
don't know what you are trying to say. I've never insulted you about it or
tried to put you down about it, I just can't reply to a post that I can't
make out is all.

Happy holidays!

-Scott

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eQ**************@TK2MSFTNGP04.phx.gbl...
Michel,

Don't listen to those who say something about your English. Especially
Scott had sent many complaints about my use of English (which can be very
bad but the same is with Dutch when I do it quick). What he does not know
that the status of English in our country is the same as in the USA. It
has no official status. The only difference is probably that percentage
wise in Holland more people can and do speak English than in the USA. And
like those Americans do we have our own dialect if we are speaking or
writing quick.

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:O9**************@TK2MSFTNGP03.phx.gbl...
>Hello Robin S.

it is now 3:40 AM the people have just left :-)

To me your opinion sure does mather , cause as i am not a native English
speaker and live in a country where something that is spoken may mean
something totally different when translated direcly to other languages,
i am sometimes confused if it is my style of writing or just the other
side that is missing my point .

So thank you verry much
regards

Michel
"RobinS" <Ro****@NoSpam.yah.noneschreef in bericht
news:KZ******************************@comcast.com ...
>>Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
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



Dec 25 '06 #17
Scott,

No problems at all, we both are already so long at these boards, it is
Christmas evening here and have just fun. You should see the smile on my
face when I write things like this.

:-)

Happy Christmas an fine holidays for you too.

Cor

"Scott M." <s-***@nospam.nospamschreef in bericht
news:e2**************@TK2MSFTNGP02.phx.gbl...
Cor, the only thing I've ever said about your English is that, at times, I
don't know what you are trying to say. I've never insulted you about it
or tried to put you down about it, I just can't reply to a post that I
can't make out is all.

Happy holidays!

-Scott

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eQ**************@TK2MSFTNGP04.phx.gbl...
>Michel,

Don't listen to those who say something about your English. Especially
Scott had sent many complaints about my use of English (which can be very
bad but the same is with Dutch when I do it quick). What he does not know
that the status of English in our country is the same as in the USA. It
has no official status. The only difference is probably that percentage
wise in Holland more people can and do speak English than in the USA. And
like those Americans do we have our own dialect if we are speaking or
writing quick.

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:O9**************@TK2MSFTNGP03.phx.gbl...
>>Hello Robin S.

it is now 3:40 AM the people have just left :-)

To me your opinion sure does mather , cause as i am not a native English
speaker and live in a country where something that is spoken may mean
something totally different when translated direcly to other languages,
i am sometimes confused if it is my style of writing or just the other
side that is missing my point .

So thank you verry much
regards

Michel
"RobinS" <Ro****@NoSpam.yah.noneschreef in bericht
news:KZ******************************@comcast.co m...
Michel,

Not that my opinion matters, but I was really impressed by your
response. It must have taken you a while to create, and I thought
it really explained things well, along with explaining *why* you
were explaining them because of the history of the posting.

Have a nice 3 Christmases.

Robin S.
---------------------------------------------
"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eX**************@TK2MSFTNGP06.phx.gbl...
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
>




Dec 25 '06 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: William C. White | last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using cURL? Our website is hosted on a shared drive and the webhost company doesn't installed additional software (such as cURL)...
2
by: Albert Ahtenberg | last post by:
Hello, I don't know if it is only me but I was sure that header("Location:url") redirects the browser instantly to URL, or at least stops the execution of the code. But appearantely it continues...
3
by: James | last post by:
Hi, I have a form with 2 fields. 'A' 'B' The user completes one of the fields and the form is submitted. On the results page I want to run a query, but this will change subject to which...
0
by: Ollivier Robert | last post by:
Hello, I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9 system. The link succeeds but everytime I try to run php, I get a SEGV from inside the libcnltsh.so library. ...
1
by: Richard Galli | last post by:
I want viewers to compare state laws on a single subject. Imagine a three-column table with a drop-down box on the top. A viewer selects a state from the list, and that state's text fills the...
4
by: Albert Ahtenberg | last post by:
Hello, I have two questions. 1. When the user presses the back button and returns to a form he filled the form is reseted. How do I leave there the values he inserted? 2. When the...
1
by: inderjit S Gabrie | last post by:
Hi all Here is the scenerio ...is it possibly to do this... i am getting valid course dates output on to a web which i have designed ....all is okay so far , look at the following web url ...
2
by: Jack | last post by:
Hi All, What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g. select x from y where z=:parameter Which in asp/jsp would be followed by some statements to bind a value...
3
by: Sandwick | last post by:
I am trying to change the size of a drawing so they are all 3x3. the script below is what i was trying to use to cut it in half ... I get errors. I can display the normal picture but not the...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.