Re: Any REAL reason to use ADO vs. DAO?
- From: Paul Clement <UseAdddressAtEndofMessage@xxxxxxxxxxxxxx>
- Date: Fri, 04 May 2007 08:14:05 -0500
On Wed, 2 May 2007 17:21:25 -0400, "Jim Carlock" <anonymous@localhost> wrote:
¤ 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.
You were using examples of applications where you believed DAO was used. The question was, is it
actually DAO or Jet? Maybe you could answer that now that you know the difference?
¤ : 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.
Yes, you're missing out. ;-)
I thought my explanation above was rather clear, but maybe you don't have a need to pass Recordset
objects between processes and have never tried it with DAO.
¤ : 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?
This has nothing to do file size. It has to do with the size of the objects in memory and
capability.
¤ : 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>
Right. DAO360.DLL is the DAO object library. MSJET40.DLL is the Jet database engine.
MSJETOLEDB40.dll is the Jet OLEDB Provider, used by ADO.
Paul
~~~~
Microsoft MVP (Visual Basic)
.
- Follow-Ups:
- Re: Any REAL reason to use ADO vs. DAO?
- From: Robert Morley
- Re: Any REAL reason to use ADO vs. DAO?
- References:
- Re: Any REAL reason to use ADO vs. DAO?
- From: Paul Clement
- Re: Any REAL reason to use ADO vs. DAO?
- From: Jim Carlock
- Re: Any REAL reason to use ADO vs. DAO?
- From: Paul Clement
- Re: Any REAL reason to use ADO vs. DAO?
- From: Jim Carlock
- Re: Any REAL reason to use ADO vs. DAO?
- From: Paul Clement
- Re: Any REAL reason to use ADO vs. DAO?
- From: Jim Carlock
- Re: Any REAL reason to use ADO vs. DAO?
- Prev by Date: Re: Getting 'Project or Library not found'
- Next by Date: vb6 com+ out of memory issue
- Previous by thread: Re: Any REAL reason to use ADO vs. DAO?
- Next by thread: Re: Any REAL reason to use ADO vs. DAO?
- Index(es):
Relevant Pages
|
Loading