Re: Any REAL reason to use ADO vs. DAO?

"Paul Clement" commented...
: Most performance issues are not observable. In other words,
: there is less significance than there would be if say for example,
: a feature was not available.

Maybe my one bad experience with ADODB in 1998 where
a DAO connection over a telephone line took an hour to
download the data via DAO, and trying the same thing via
ADODB took over 24 hours... I ended up using VB to run
make table queries inside of Access for the best times, and
then used DAO to run various parameterized queries, 15 or
20 of them to get the data into the proper formats). It involved
a localized Access database where a VB5 app (project started
with VB5 and later ended up in VB6) connected to the .mdb
using DAO objects (and tested with ADODB objects as wells).

I understand that the make table queries were Jet (?), and all the
parameterized queries were all Jet (?). The VB objects used to run
those queries were DAO and ADODB. Not at the same time, as
I tested each on their own.

I'm not really sure where Jet comes in, but if I were to guess, I
think it involves the fact that msaccess.exe imports quite a few
functions from various JET files. Am I correct in the way I under-
stand the way that works? IF that is the way it works, I don't see
how JET really applies to this discussion. It's the VB application
that employs DAO or ADODB, and it's Access that does JET.

: In addition, the performance difference is rather specific to an
: Access database. That's because there's an extra layer involved
: on the ADO side (OLEDB). There is no inherent performance
: advantage to using DAO/ODBC over ADO/OLEDB for other
: database types, and ADO/OLEDB does not require a DSN to
: resolve a connection.

Should we create some kind of test to validate that. Hmmm...
Need alot of data... let me look for some zip code stuff. I used
to have a database of zip codes. It's kind of dated back to 1995
or thereabouts (from the age when dual-speed CD ROMs just
swamped the computer stores, the days of DOS 6 and Windows
3.11).

: Sure it's really easy. Try passing a DAO Recordset from a client
: app to an out of process component, such as an ActiveX EXE
: or an ActiveX DLL running under COM+.

You mean start up Excel and go into VBA there (Excel is ActiveX,
right?), and then click on the References there and check mark
Microsoft DAO? That's kind of cheating because VBA is built into
Excel, but it fits your suggestion. So we build an ActiveX app with
VB that connects via DAO or ADODB... Either way, either I'm
missing out on what you're suggesting or I don't see it as a problem.

Microsoft should just provide the VBA free of charge for everyone
to put it into their apps. Is that possible without buying Microsoft? I
mean, it would greatly enhance all Microsoft operating systems and
support Microsoft products alot.

: Point being, the DAO objects are somewhat bloated in addition
: to being persistently connected to the data source.

Huhh? LOL. Bloated? I don't mean to laugh, but can you explain
exactly what you mean? dao360.dll ? That's bloat? One file? I'm
not sure what you mean! Come on, Paul. Are you serious?

: DAO is an easy to use COM based programmatic object
: model that interfaces with Jet. Jet is the underlying database
: engine technology.
:
: Jet and DAO are distributed through the Jet database engine
: components. ADO is distributed through MDAC.

I'm looking at the MDAC2.8 installation folder...
"jetfiles.cab", "Thursday, July 17, 2003, 9:38:34 AM"

I found dao360.dll inside kb829558. That was the file I was talking
about when I referenced DAO/JET. I think I've got JET figured out
now. Please correct me if I'm wrong.

Looking into what the dao360.dll provides, it imports from the following
files. I don't see anything Jet there. So I think I ended up confused by
thinking that DAO is Jet, which seems wrong. MSACCESS.EXE
imports from msjet40.dll (XP). Thanks for bringing up the JET topic.
I think I've got that sorted out now. <g>

Supposedly Windows runs on Linux now. I haven't messed with that
as of yet. I spot some CygWin information every so often, sometimes
in this newsgroup. But that's a whole other topic.

And I ran across that again yesterday while perusing a slackware
linux site. Whole other topic.

--
Jim Carlock
Post replies to the group.

Off-topic comments...
PHP runs very well and IS a better Visual Basic for websites than
IIS 5. We won't get into IIS 6 and their whole new slew of
document names. index.php still works whether you use PHP 4 or
PHP 5. If anyone wants any help with PHP and Apache send an
email.

at hotmail
jcarlock1
dot com


.

Relevant Pages

  • Re: Database has gigantic size
    ... DAO is simply the direct interface to JET. ... this then is exactly why the database grows so large. ... Why were updates within recordsets so ...
    (microsoft.public.vb.database)
  • Re: Sign In/Out Program
    ... ADO is capable of MULTI USER that the database is open by many user at ... used DAO and ms access database for single user only. ... DAO works well with Jet. ... but mdb is a file-based database and will have the same ...
    (microsoft.public.vb.general.discussion)
  • Re: Missing DAO licence on target PC
    ... compare SQL + ADO to JET + DAO ... but JET is obsolete; and who wants to use an obsolete DAL just because ... DAO and JET have both been obsoleted for a decade. ... DAO doesn't fit into the 'worlds most popular database' and it hasn't ...
    (microsoft.public.dotnet.languages.vb)
  • Re: How to enforce subtypes/supertypes in Access 2000?
    ... DAO is the native object model for Jet databases and, as such, is the ... ever need ADO. ... Private Sub SetContactType() ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Speichernutzung von .NET-Anwendungen
    ... und dennoch weiterhin DAO verwenden. ... Neuentwicklungen und die Vorteile bisheriger Techniken gegenseitig ... > Zugriff auf die Jet Engine. ... Technologie bei dem ursprünglichen "DBMS" (Access) mehr besteht? ...
    (microsoft.public.de.german.entwickler.dotnet.vb)