Benchmarks: ADO versus DAO

Dated or intended to be discontinued?

From a management point-of-view, there's a big difference.

I know DAO is old. It's why I'm posting, but is it about to be canned? If
anyone has anything pointing to Microsoft's opinion on future DAO support,
I'd love to print it out.

Thanks,

Casey

"Paul Clement" <UseAdddressAtEndofMessage RemoveThis @swspectrum.com> wrote in message
news:hk0jvvo2d9i0lm6eq16qpgdgl3egaj063k@4ax.com...
 > On Mon, 5 Jan 2004 09:58:47 -0500, "Casey" <clengacher RemoveThis @smcky.com> wrote:
 >
 > ¤ Greetings:
 > ¤
 > ¤ I currently have an application written in VB 6.0 that uses the Data
 > ¤ Enviroment Designer (ADO control) to interact using Jet 3.51 with an
Access
 > ¤ 97 database.
 > ¤
 > ¤ What I've noticed over the life cycle is that queries I made in Access
 > ¤ seemed to run on the order of tenths of seconds, but accessing that same
 > ¤ collection of data via the Data Environment took orders of tens of
seconds.
 > ¤
 > ¤ This boggled me. If Access could query in .15 seconds, why was it taking
7
 > ¤ seconds in VB?
 > ¤
 > ¤ So I did a benchmark where I specifically open the data set using DAO
versus
 > ¤ ADO with no pre-compiled query definitions. Just raw SQL strings in VB
code.
 > ¤ I was blown away at the speed difference. 5 executions of the query
using
 > ¤ ADO took nearly 30 seconds while it only took 7 seconds using DAO.
 > ¤
 > ¤ I want this speed improvement, but I'm concerned it might not be worth
it.
 > ¤ We're eventually heading to SQL server, would replacing ADO with DAO be
a
 > ¤ bad move if that's in the future?
 > ¤
 > ¤ Thoughts and opinions more than welcomed.
 > ¤
 >
 > ADO is typically slower because it adds an extra layer of data access;
OLEDB. However, DAO is
 > somewhat dated technology and it isn't the best solution for SQL Server if
that is where you are
 > headed.
 >
 > I would recommend ADO for VB 6.0 and ADO.NET for VB.NET applications.
 >
 >
 > Paul ~~~ pclement RemoveThis @ameritech.net
 > Microsoft MVP (Visual Basic)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

"Casey" <clengacher.DeleteThis@smcky.com> wrote in message <news:#JNYmN60DHA.2000@TK2MSFTNGP11.phx.gbl>...

 > Dated or intended to be discontinued?
 >
 > From a management point-of-view, there's a big difference.
 >
 > I know DAO is old. It's why I'm posting, but is it about to be canned? If
 > anyone has anything pointing to Microsoft's opinion on future DAO support,
 > I'd love to print it out.

Micro$haft has been trying to can DAO for quite some time:

URL:http://msdn.microsoft.com/library/en-us/mdacsdk/htm/mdac_deprecated.asp

After all, if you insist on using DAO, you won't have enough incentives
to spring for SQL Server Enterprise Advanced running atop Windows Server
2003 Advanced Enterprise in order to work around ADO and MSDE limitations!

--
Joe Foster <mailto:jlfoster%40znet.com> Greed = God? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

Thank you VERY MUCH.

The MDAC Road Map, the container of the document link you posted, was
exactly what I needed to prove that my "crazy notions for software
development and IT steering" are actually right on par considering that the
last year or so I've been implementing code that is not considered
"obsolete".

Nonetheless, saddens me to see this. I guess till our complete conversion
from Access to SQL is complete, there will be some speed issues. Either way,
I'd rather have speed issues with half my conversion process complete than
have faster code that was already obsolete the day it was released.

Just from a liability point of view. :p

Once again, thanks.

Casey

"Joe "Nuke Me Xemu" Foster" <joe.DeleteThis@bftsi0.UUCP> wrote in message
news:%23pV9yH90DHA.832@TK2MSFTNGP09.phx.gbl...
 > "Casey" <clengacher.DeleteThis@smcky.com> wrote in message
<news:#JNYmN60DHA.2000@TK2MSFTNGP11.phx.gbl>...
 >
  > > Dated or intended to be discontinued?
  > >
  > > From a management point-of-view, there's a big difference.
  > >
  > > I know DAO is old. It's why I'm posting, but is it about to be canned?
If
  > > anyone has anything pointing to Microsoft's opinion on future DAO
support,
  > > I'd love to print it out.
 >
 > Micro$haft has been trying to can DAO for quite some time:
 >
 >
URL:http://msdn.microsoft.com/library/en-us/mdacsdk/htm/mdac_deprecated.asp
 >
 > After all, if you insist on using DAO, you won't have enough incentives
 > to spring for SQL Server Enterprise Advanced running atop Windows Server
 > 2003 Advanced Enterprise in order to work around ADO and MSDE limitations!
 >
 > --
 > Joe Foster <mailto:jlfoster%40znet.com> Greed = God?
<http://www.xenu.net/>
 > WARNING: I cannot be held responsible for the above They're
coming to
 > because my cats have apparently learned to type. take me away,
ha ha!
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

"Casey" <clengacher.RemoveThis@smcky.com> wrote in message <news:ui5rpm90DHA.2636@TK2MSFTNGP09.phx.gbl>...

 > Thank you VERY MUCH.
 >
 > The MDAC Road Map, the container of the document link you posted, was
 > exactly what I needed to prove that my "crazy notions for software
 > development and IT steering" are actually right on par considering that the
 > last year or so I've been implementing code that is not considered
 > "obsolete".
 >
 > Nonetheless, saddens me to see this. I guess till our complete conversion
 > from Access to SQL is complete, there will be some speed issues. Either way,
 > I'd rather have speed issues with half my conversion process complete than
 > have faster code that was already obsolete the day it was released.
 >
 > Just from a liability point of view. :p

Actually, Visual Basic, ADO, and everything else is "obsolete" too!
Don't you know you are supposed to trash, redesign, and rewrite
everything from *scratch* in B#, C#, and ADO.NET? Oh yeah, you'll
also have to migrate everything yet *again* to Longhorn's 'new and
improved' WinFX and WinFS APIs, since Win32 itself is destined for
the trash heap as well. Even C++ is also being proprietarized.

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

On Mon, 5 Jan 2004 10:48:38 -0500, "Casey" <clengacher RemoveThis @smcky.com> wrote:

¤ Dated or intended to be discontinued?

It's dated but Microsoft continues to support DAO.

Microsoft has tried to kill DAO several times, but it keeps coming back. I was told that the
article, that Joe pointed out, was to be amended. That was about five months ago.

In any event, *officially* Microsoft still supports DAO. How long they will continue to support it
(given that there have been no enhancements since Access 2000 and MSDE is the recommended desktop
replacement) is anybody's guess.


Paul ~~~ pclement RemoveThis @ameritech.net
Microsoft MVP (Visual Basic)
 >> Stay informed about: Benchmarks: ADO versus DAO 

Still, from a liability point of view, you have to go with what's published.
Now if something with a more recent data goes to the extents of reversing
Microsot statement

"Do no use these technologies when you write new applications."

Then so be it. I'll print that out and have it in my arsenal. To me, this is
more of a protecting my butt exercise than anything.

See, we have an environment where two people are doing most the programming.
Two years ago, I switched to programming using ADO while my counterpart
continued to implement new software using DAO. I can understand that, it's
faster, but it's also older. But he also continued to program in Access's
VBA and I jumped ship to VB 6.0 after the Access 2.0 to Access 97 run
around.

What this boils down to is if DAO really isn't going to be supported in
Win64, the craps gonna hit the fan when our armada of Access 97 databases
(hope that makes some people smile cause to me the mental image is fun as
heck) using his DAO have to be upgraded. To boot, our upgrade cycle isn't
really optional. We interface with over 20 leading edge companies which
generally tend to implement new technologies within weeks of availablity.
It'd only be a matter of time.

Thanks for the feedback. At the core, I realize what is the most efficient
thing to do here might not be the "right" thing to do, but I can't recommend
using a technology if the supplier of the technology says it's being canned.
That's just a real stupid thing to do and honestly, can get ya fired.

Casey

"Paul Clement" <UseAdddressAtEndofMessage DeleteThis @swspectrum.com> wrote in message
news:pdhlvvcbbebeilf5tjibpcf42k0g0qpk3n@4ax.com...
 > On Mon, 5 Jan 2004 10:48:38 -0500, "Casey" <clengacher DeleteThis @smcky.com> wrote:
 >
 > ¤ Dated or intended to be discontinued?
 >
 > It's dated but Microsoft continues to support DAO.
 >
 > Microsoft has tried to kill DAO several times, but it keeps coming back. I
was told that the
 > article, that Joe pointed out, was to be amended. That was about five
months ago.
 >
 > In any event, *officially* Microsoft still supports DAO. How long they
will continue to support it
 > (given that there have been no enhancements since Access 2000 and MSDE is
the recommended desktop
 > replacement) is anybody's guess.
 >
 >
 > Paul ~~~ pclement DeleteThis @ameritech.net
 > Microsoft MVP (Visual Basic)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

 > Thanks for the feedback. At the core, I realize what is the most efficient
 > thing to do here might not be the "right" thing to do, but I can't recommend
 > using a technology if the supplier of the technology says it's being canned.
 > That's just a real stupid thing to do and honestly, can get ya fired.

There used to be a saying that "Nobody ever got fired for buying IBM". While
that may have been true there were a lot of people who got left in the dust by
following IBM.

We may be in similar point in history right now.

Microsoft continues to push the market to more complex solutions that may or
may not be the best tool for many jobs. In your case you have an app that from
your testing is going to slow WAY DOWN by using ADO. If I were your boss I
would fire you for slowing productivity just because some vendor said the
faster technology was "old".

My suggestion is to use DAO if it does what you need and is faster. Write your
applications in a modular fashion so changing the data access methods does not
require crawling through every line of code. As an alternative you might want
to check out MySQL and the ODBCless connectors from either of these folks:

<a style='text-decoration: underline;' href="http://www.icarz.com/mysql/" target="_blank">http://www.icarz.com/mysql/</a>
<a style='text-decoration: underline;' href="http://www.scibit.com/Products/Software/MySQLX/default.htm" target="_blank">http://www.scibit.com/Products/Software/MySQLX/default.htm</a>

In the end all technology ends up getting "canned".<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

DAO is built on the Jet database engine, which is built on
the database semantics of DOS 3.x, based on the FAT file
system. Jet is fast, easy to install, and has a small
footprint. This is why my customers like it.

There is a new file system in the next version of Windows.
This time, the new file system has a new database interface,
which responds directly to T-SQL. My customers will
have this database system installed when they install
Windows.

Logically, there is no reason to continue development of
Jet once the new file system and OS come into use. Instead,
a new database engine should be built that uses the new
file database API instead of the old DOS file database API.
The new database engine would be fast, easy to install, and
have a small footprint. The object model would be like
ADO (it is more difficult to use, but it makes a fashion
statement), and the speed would be like DAO.

However, Access and Jet development have been a very low
priority since Access 2.0. (Win 3.1). In fact, functionality
was trimmed in A97, and again in A2K (although new features
were added, things like Transaction Handling were broken).

So no new work will be done on Jet and DAO, but they will
continue to limp along, because the work on the replacement
won't get done either. Applications will continue to drift
to SQL Server. DAO,JET and Access will go the way of DBASE
and FoxPro.

(david)





"Casey" <clengacher.DeleteThis@smcky.com> wrote in message
news:%23JNYmN60DHA.2000@TK2MSFTNGP11.phx.gbl...
 > Dated or intended to be discontinued?
 >
 > From a management point-of-view, there's a big difference.
 >
 > I know DAO is old. It's why I'm posting, but is it about to be canned? If
 > anyone has anything pointing to Microsoft's opinion on future DAO support,
 > I'd love to print it out.
 >
 > Thanks,
 >
 > Casey
 >
 > "Paul Clement" <UseAdddressAtEndofMessage.DeleteThis@swspectrum.com> wrote in message
 > news:hk0jvvo2d9i0lm6eq16qpgdgl3egaj063k@4ax.com...
  > > On Mon, 5 Jan 2004 09:58:47 -0500, "Casey" <clengacher.DeleteThis@smcky.com> wrote:
  > >
  > > ¤ Greetings:
  > > ¤
  > > ¤ I currently have an application written in VB 6.0 that uses the Data
  > > ¤ Enviroment Designer (ADO control) to interact using Jet 3.51 with an
 > Access
  > > ¤ 97 database.
  > > ¤
  > > ¤ What I've noticed over the life cycle is that queries I made in Access
  > > ¤ seemed to run on the order of tenths of seconds, but accessing that
same
  > > ¤ collection of data via the Data Environment took orders of tens of
 > seconds.
  > > ¤
  > > ¤ This boggled me. If Access could query in .15 seconds, why was it
taking
 > 7
  > > ¤ seconds in VB?
  > > ¤
  > > ¤ So I did a benchmark where I specifically open the data set using DAO
 > versus
  > > ¤ ADO with no pre-compiled query definitions. Just raw SQL strings in VB
 > code.
  > > ¤ I was blown away at the speed difference. 5 executions of the query
 > using
  > > ¤ ADO took nearly 30 seconds while it only took 7 seconds using DAO.
  > > ¤
  > > ¤ I want this speed improvement, but I'm concerned it might not be worth
 > it.
  > > ¤ We're eventually heading to SQL server, would replacing ADO with DAO
be
 > a
  > > ¤ bad move if that's in the future?
  > > ¤
  > > ¤ Thoughts and opinions more than welcomed.
  > > ¤
  > >
  > > ADO is typically slower because it adds an extra layer of data access;
 > OLEDB. However, DAO is
  > > somewhat dated technology and it isn't the best solution for SQL Server
if
 > that is where you are
  > > headed.
  > >
  > > I would recommend ADO for VB 6.0 and ADO.NET for VB.NET applications.
  > >
  > >
  > > Paul ~~~ pclement.DeleteThis@ameritech.net
  > > Microsoft MVP (Visual Basic)
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

probably true - but they do seem to make it ever more difficult to simply
deploy
a simple access database app over a variety of OS's... its ok for larger
companies to
an extent, but they're really missing the boat with the small-fry...


"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:uSUoF$b2DHA.1684@TK2MSFTNGP12.phx.gbl...
 > DAO is built on the Jet database engine, which is built on
 > the database semantics of DOS 3.x, based on the FAT file
 > system. Jet is fast, easy to install, and has a small
 > footprint. This is why my customers like it.
 >
 > There is a new file system in the next version of Windows.
 > This time, the new file system has a new database interface,
 > which responds directly to T-SQL. My customers will
 > have this database system installed when they install
 > Windows.
 >
 > Logically, there is no reason to continue development of
 > Jet once the new file system and OS come into use. Instead,
 > a new database engine should be built that uses the new
 > file database API instead of the old DOS file database API.
 > The new database engine would be fast, easy to install, and
 > have a small footprint. The object model would be like
 > ADO (it is more difficult to use, but it makes a fashion
 > statement), and the speed would be like DAO.
 >
 > However, Access and Jet development have been a very low
 > priority since Access 2.0. (Win 3.1). In fact, functionality
 > was trimmed in A97, and again in A2K (although new features
 > were added, things like Transaction Handling were broken).
 >
 > So no new work will be done on Jet and DAO, but they will
 > continue to limp along, because the work on the replacement
 > won't get done either. Applications will continue to drift
 > to SQL Server. DAO,JET and Access will go the way of DBASE
 > and FoxPro.
 >
 > (david)
 >
 >
 >
 >
 >
 > "Casey" <clengacher.TakeThisOut@smcky.com> wrote in message
 > news:%23JNYmN60DHA.2000@TK2MSFTNGP11.phx.gbl...
  > > Dated or intended to be discontinued?
  > >
  > > From a management point-of-view, there's a big difference.
  > >
  > > I know DAO is old. It's why I'm posting, but is it about to be canned?
If
  > > anyone has anything pointing to Microsoft's opinion on future DAO
support,
  > > I'd love to print it out.
  > >
  > > Thanks,
  > >
  > > Casey
  > >
  > > "Paul Clement" <UseAdddressAtEndofMessage.TakeThisOut@swspectrum.com> wrote in
message
  > > news:hk0jvvo2d9i0lm6eq16qpgdgl3egaj063k@4ax.com...
   > > > On Mon, 5 Jan 2004 09:58:47 -0500, "Casey" <clengacher.TakeThisOut@smcky.com>
wrote:
   > > >
   > > > ¤ Greetings:
   > > > ¤
   > > > ¤ I currently have an application written in VB 6.0 that uses the Data
   > > > ¤ Enviroment Designer (ADO control) to interact using Jet 3.51 with an
  > > Access
   > > > ¤ 97 database.
   > > > ¤
   > > > ¤ What I've noticed over the life cycle is that queries I made in
Access
   > > > ¤ seemed to run on the order of tenths of seconds, but accessing that
 > same
   > > > ¤ collection of data via the Data Environment took orders of tens of
  > > seconds.
   > > > ¤
   > > > ¤ This boggled me. If Access could query in .15 seconds, why was it
 > taking
  > > 7
   > > > ¤ seconds in VB?
   > > > ¤
   > > > ¤ So I did a benchmark where I specifically open the data set using
DAO
  > > versus
   > > > ¤ ADO with no pre-compiled query definitions. Just raw SQL strings in
VB
  > > code.
   > > > ¤ I was blown away at the speed difference. 5 executions of the query
  > > using
   > > > ¤ ADO took nearly 30 seconds while it only took 7 seconds using DAO.
   > > > ¤
   > > > ¤ I want this speed improvement, but I'm concerned it might not be
worth
  > > it.
   > > > ¤ We're eventually heading to SQL server, would replacing ADO with DAO
 > be
  > > a
   > > > ¤ bad move if that's in the future?
   > > > ¤
   > > > ¤ Thoughts and opinions more than welcomed.
   > > > ¤
   > > >
   > > > ADO is typically slower because it adds an extra layer of data access;
  > > OLEDB. However, DAO is
   > > > somewhat dated technology and it isn't the best solution for SQL
Server
 > if
  > > that is where you are
   > > > headed.
   > > >
   > > > I would recommend ADO for VB 6.0 and ADO.NET for VB.NET applications.
   > > >
   > > >
   > > > Paul ~~~ pclement.TakeThisOut@ameritech.net
   > > > Microsoft MVP (Visual Basic)
  > >
  > >
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO 

"Flying Pig" <flying RemoveThis @nopigsorspam.com> wrote in message
news:400739f9$0$9394$cc9e4d1f@news-text.dial.pipex.com...
 > probably true - but they do seem to make it ever more difficult to simply
 > deploy
 > a simple access database app over a variety of OS's... its ok for larger
 > companies to
 > an extent, but they're really missing the boat with the small-fry...
 >


To be fair, MS is working on generic deployment, based on IE.
Like VB/VB.NET, If Access ever becomes easy to deploy, it will
be at the cost of such changes that it won't really be Access
any more.

(david)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Benchmarks: ADO versus DAO