DAO.Recordset vs ADO.Recordset 
Author Message
 DAO.Recordset vs ADO.Recordset

What is the difference between

Dim rst as DAO.Recordset

and

Dim rst as ADO.Recordset ?

It seems that some functions and/or properties are available with one
and not with the other.

As an exemple, I'm getting an error on the following code line
(extracted from MS Visual Basic 6 Help !)

If rst.NoMatch
...
...
EndIf

The highlighted error portion beeing ?.NoMatch?

I'm new with VB and I have read the meaning of each 3 letters, but I
don't realy understand the difference.  It seems very important since
on many occasions, the documentation will put either ADO or DAO in
brackets after a function or property.

Thank you for any help I can get



Fri, 24 Jun 2005 02:18:49 GMT  
 DAO.Recordset vs ADO.Recordset
Actually, it's Dim rst As ADODB.Recordset, not Dim rst As ADO.Recordset

ADO and DAO are two different approaches to getting at data. Both of them
have an object named Recordset in their model which holds the data that's
returned, but they're different things.

The following articles should help explain the differences:

INFO: Issues Migrating from DAO/Jet to ADO/Jet
http://support.microsoft.com/default.aspx?scid=kb;[LN[;225048
Porting DAO Code to ADO with the Microsoft Jet Provider
http://msdn.microsoft.com/library/en-us/dndao/html/daotoado.asp
Migrating from DAO to ADO
http://msdn.microsoft.com/library/en-us/dndao/html/daotoadoupdate.asp
The ADO Rosetta Stone
http://msdn.microsoft.com/library/en-us/dnado/html/msdn_adorosest.asp

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele


Quote:
> What is the difference between

> Dim rst as DAO.Recordset

> and

> Dim rst as ADO.Recordset ?

> It seems that some functions and/or properties are available with one
> and not with the other.

> As an exemple, I'm getting an error on the following code line
> (extracted from MS Visual Basic 6 Help !)

> If rst.NoMatch
> ...
> ...
> EndIf

> The highlighted error portion beeing ?.NoMatch?

> I'm new with VB and I have read the meaning of each 3 letters, but I
> don't realy understand the difference.  It seems very important since
> on many occasions, the documentation will put either ADO or DAO in
> brackets after a function or property.

> Thank you for any help I can get



Fri, 24 Jun 2005 02:23:59 GMT  
 DAO.Recordset vs ADO.Recordset

Thanks for your quick response.

I  should find the required info in the mentionned reference.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Fri, 24 Jun 2005 02:51:37 GMT  
 DAO.Recordset vs ADO.Recordset

...

Quote:

>As an exemple, I'm getting an error on the following code line
>(extracted from MS Visual Basic 6 Help !)

>If rst.NoMatch
>...
>...
>EndIf

>The highlighted error portion beeing ?.NoMatch?

...

You didn't say if you were trying this with a DAO or ADO recordset,
but I'm assuming it was ADO because ADO recordsets have no NoMatch
property.  Instead, after a search fails, .EOF will be true.



Fri, 24 Jun 2005 03:07:02 GMT  
 DAO.Recordset vs ADO.Recordset

Steve,

The big part of the problem is exactly this: I'm not sure which library
I'm using and I don't know how to declare which one I want to use.
Further, I don't know which one is better.  Are both method possible
with Access ?

I'm starting the development of an application using MS Access 2000 and
some VB code (VB 6).

I have started to read the documentation you pointed out, but ...

I have developped a lot of applications in Clipper and I'm now trying to
use Access to convert one big and complex Clipper app.  It will take few
hours of digging out, I beleive, before I can write code in VB for
Access as easily as I did in Clipper 87.

Thanks for your help.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Fri, 24 Jun 2005 03:31:37 GMT  
 DAO.Recordset vs ADO.Recordset
You can use both. If you want to use both, you need to ensure that your VB
project has references to both the DAO 3.6 Object Library and the ActiveX
Data Objects Library. (I'm not sure which version of the latter to
recommend. Most of the features added in the latest versions are likely to
remain unused in most apps, and the earlier versions are more likely to be
already present on the target PC. Perhaps someone else might want to comment
on that?)

Once you have references to both, you can specify the library to use when
declaring the variable, Dim rst As DAO.Recordset or Dim rst As
ADODB.Recordset. (Note, it's ADODB, not ADO. There are actually three ADO
libraries, the ActiveX Data Object Library (ADODB), the ActiveX Data Objects
Recordset Library (ADOR), which is a light-weight version designed for use
in web applications, and the ADO Ext. for DDL and Security Library (ADOX).

You also need to remember that an ADO method that returns a recordset will
always return an ADO recordset, and a DAO method that returns a recordset
will always return a DAO recordset, and you can't assign that recordset to
the wrong type of recordset variable. For example, if you declared a
variable using Dim rst As DAO.Recordset, you can't assign the result of the
ADO Connection.Execute method to that variable, because the method returns
an ADO recordset. Similarly, if you declared the variable using Dim rst As
ADODB.Recordset, you can't assign the recordset returned by
DBEngine.OpenRecordset() to that variable, because DBEngine.OpenRecordset
returns a DAO recordset.

As for which library is best, that has been a subject of often heated
discussion for years now. Most Access developers see little, if any, reason
to use ADO when the front-end is Access and the back-end is Jet, but I'm not
so sure whether that still holds when the front-end is in VB.

One reason that was often put forward in the past for using ADO was because
ADO was supposed to be the 'future of data access technology' while DAO was
obsolete, but classic ADO is now just as obsolete as DAO - the future
according to Microsoft is ADO.NET, which despite the name is not a new
version of ADO but a new data access technology.

The article at the following URL is well worth a read, and if you're going
to be using VB, you might want to try posting a question to one of the VB
newsgroups such as comp.lang.basic.visual.database or
microsoft.public.vb.database

http://www.trigeminal.com/usenet/usenet025.asp?1033

--
Brendan Reynolds


Quote:

> Steve,

> The big part of the problem is exactly this: I'm not sure which library
> I'm using and I don't know how to declare which one I want to use.
> Further, I don't know which one is better.  Are both method possible
> with Access ?

> I'm starting the development of an application using MS Access 2000 and
> some VB code (VB 6).

> I have started to read the documentation you pointed out, but ...

> I have developped a lot of applications in Clipper and I'm now trying to
> use Access to convert one big and complex Clipper app.  It will take few
> hours of digging out, I beleive, before I can write code in VB for
> Access as easily as I did in Clipper 87.

> Thanks for your help.

> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!



Fri, 24 Jun 2005 04:00:48 GMT  
 DAO.Recordset vs ADO.Recordset

Quote:
> I have developped a lot of applications in Clipper and I'm now trying to
> use Access to convert one big and complex Clipper app.  It will take few
> hours of digging out, I beleive, before I can write code in VB for
> Access as easily as I did in Clipper 87.

I've been trying for 10 years and I'm not there YET!

Clipper (or is it just the Clipper of Nostalgia?????????)

was the greatest ... before the cretins of Computer Associates got hold of
it, of course.

"Things ain't what they used to be and never were" ... Will Rogers.

--
Lyle



Fri, 24 Jun 2005 04:04:42 GMT  
 DAO.Recordset vs ADO.Recordset

Quote:



>>I have developped a lot of applications in Clipper and I'm now trying to
>>use Access to convert one big and complex Clipper app.  It will take few
>>hours of digging out, I beleive, before I can write code in VB for
>>Access as easily as I did in Clipper 87.

> I've been trying for 10 years and I'm not there YET!

> Clipper (or is it just the Clipper of Nostalgia?????????)

> was the greatest ... before the cretins of Computer Associates got hold of
> it, of course.

> "Things ain't what they used to be and never were" ... Will Rogers.

I *really* miss code blocks. They were great.

--
'-------------------------------
' John Mishefske
'-------------------------------



Fri, 24 Jun 2005 06:01:18 GMT  
 DAO.Recordset vs ADO.Recordset

Lyle,

I agree with your comment on Clipper, but we can't stay still... I'm
trying to convince myself !

Perhaps after the training (and straining) period, we will become as
proficient with Access and VB ?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Fri, 24 Jun 2005 06:51:34 GMT  
 DAO.Recordset vs ADO.Recordset

Quote:
> Lyle,

> I agree with your comment on Clipper, but we can't stay still... I'm
> trying to convince myself !

> Perhaps after the training (and straining) period, we will become as
> proficient with Access and VB ?

Perhaps ...

--
Lyle



Fri, 24 Jun 2005 06:55:02 GMT  
 DAO.Recordset vs ADO.Recordset


Quote:
>As for which library is best, that has been a subject of often
>heated discussion for years now. Most Access developers see
>little, if any, reason to use ADO when the front-end is Access and
>the back-end is Jet, but I'm not so sure whether that still holds
>when the front-end is in VB.

There are a few things that ADO provides that DAO does not. The
only one I can think of is the UserRoster, but that can be gotten
by using the MSLDBUSER.DLL, so I see little point in adding an ADO
reference just for that.

DAO, on the other hand, provides many, many different kinds of
functionality that ADO does not. It is also substantially faster
with Jet data than ADO, because it is the native data access
interface for Jet, whereas ADO is an abstration level above that.

Granted, ADO does have important features that DAO lacks, but those
are all designed for use with server back ends, so none of them are
relevant to interfacing with Jet data.

I can't come up with any reason for ever choosing ADO for use in an
Access or VB front end when your back end is Jet. Microsoft's
promotion of ADO in that scenario was always, and still is,
brain-dead stupid.

--
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc



Fri, 24 Jun 2005 11:26:15 GMT  
 DAO.Recordset vs ADO.Recordset
to start with, ADO is base on OLEDB. while DAO is not.

In case of NoMatch, It gives the result of RecordSet.Find.

cheers!
Prasad

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Fri, 24 Jun 2005 14:55:34 GMT  
 DAO.Recordset vs ADO.Recordset

Quote:



>>As for which library is best, that has been a subject of often
>>heated discussion for years now. Most Access developers see
>>little, if any, reason to use ADO when the front-end is Access and
>>the back-end is Jet, but I'm not so sure whether that still holds
>>when the front-end is in VB.

>There are a few things that ADO provides that DAO does not. The
>only one I can think of is the UserRoster, but that can be gotten
>by using the MSLDBUSER.DLL, so I see little point in adding an ADO
>reference just for that.

>DAO, on the other hand, provides many, many different kinds of
>functionality that ADO does not. It is also substantially faster
>with Jet data than ADO, because it is the native data access
>interface for Jet, whereas ADO is an abstration level above that.

While it's true that DAO provides some JET functionality that ADO does
not, the gap is being rapidly filled.  It helps to know that not
everything in ADO is in the ADODB, some of it is also in ADOX.  Also,
i used to believe that the ADO provider for JET was a wrapper around
DAO as you suggest, but it appears that this is not the case.  DAO and
ADO are simply different wrappers around JET.

This does not mean that I think ADO is always the best choice for use
with JET.  I think that JET is better engineered that ADO,
particularly for use with ISAM data sources, and it is definitely not
slower than ADO.  In ADO, there are always 5 ways to do any task, and
many of them won't work.

Quote:

>Granted, ADO does have important features that DAO lacks, but those
>are all designed for use with server back ends, so none of them are
>relevant to interfacing with Jet data.

I agree.  I do like disconnected recordsets - a cool, but not
compelling feature.

Quote:

>I can't come up with any reason for ever choosing ADO for use in an
>Access or VB front end when your back end is Jet. Microsoft's
>promotion of ADO in that scenario was always, and still is,
>brain-dead stupid.

It depends on your perspective.  I would say unnecessary rather than
stupid.  Microsoft wants to get everyone used to using MS SQL Server
so they can sell more copies of MS SQL Server regardless of whether
it's really the best tool for a given job.

In the latest versions of ADO and JET, the kinks are starting to get
worked out, and JET has been enhanced to support some more ANSI-like
syntax making it easier to write JET ADO code that's portable to SQL
Server.

I would be more comfortable with all of this if ADO didn't seem to be
so strangely designed.  It seems to have been more thrown together
than well thought out.  JET error handling is still more useful than
ADO, and I include client/server applications in that statement.



Fri, 24 Jun 2005 14:56:36 GMT  
 DAO.Recordset vs ADO.Recordset
"Steve Jorgensen" wrote

 > While it's true that DAO provides some
 > JET functionality that ADO does
 > not, the gap is being rapidly filled.

Steve, what is your source on this?

Microsoft has announced that there is no further development of ADO
functionality for Jet, and that like DAO and Jet itself, that is in
"maintenance mode". In fact, the last version of the Microsoft Data Access
Components to include ADO support for Jet was MDAC 2.5.

And "maintenance mode" is not nearly as good as it may sound, because the
only kind of bug that is guaranteed any maintenance is one that would kill
the shipment of another Microsoft product that is dependent on the one in
"maintenance mode".

Any enhancements, I believe, are to the successor product "ADO.NET" which,
AFAIK, you can't use with Access.



Sat, 25 Jun 2005 03:05:22 GMT  
 DAO.Recordset vs ADO.Recordset


Quote:




>>>As for which library is best, that has been a subject of often
>>>heated discussion for years now. Most Access developers see
>>>little, if any, reason to use ADO when the front-end is Access
>>>and the back-end is Jet, but I'm not so sure whether that still
>>>holds when the front-end is in VB.

>>There are a few things that ADO provides that DAO does not. The
>>only one I can think of is the UserRoster, but that can be gotten
>>by using the MSLDBUSER.DLL, so I see little point in adding an
>>ADO reference just for that.

>>DAO, on the other hand, provides many, many different kinds of
>>functionality that ADO does not. It is also substantially faster
>>with Jet data than ADO, because it is the native data access
>>interface for Jet, whereas ADO is an abstration level above that.

>While it's true that DAO provides some JET functionality that ADO
>does not, the gap is being rapidly filled.  It helps to know that
>not everything in ADO is in the ADODB, some of it is also in ADOX.
> Also, i used to believe that the ADO provider for JET was a
>wrapper around DAO as you suggest, . . .

I did not intentionally suggest anything of the sort, though I can
see why you read it that way. What I was trying to say is that DAO
is basically a part of the Jet substructure, designed to interface
directly with Jet, and wholly specific to Jet (unless Jet is using
ODBC to connect to a different data source), whereas ADO is an
abstraction layer that sits on top of a translation layer for a
specific database engine.

Quote:
> . . . but it appears that this is not
>the case.  DAO and ADO are simply different wrappers around JET.

Not true. ADO is an abstraction layer for *all* database engines
that provide ADO access, just as ODBC is an abstraction for every
database engine that provides an ODBC driver. ODBC sits on top of a
translation layer between standard ODBC commands and the quirks of
the individual database engines. ADO is no different than ODBC in
regard to its structural relation to the underlying data stores --
it is simply far more advanced than ODBC, and designed from the
ground up for server databases (which ODBC really wasn't, so far as
I can tell).

Quote:
>This does not mean that I think ADO is always the best choice for
>use with JET. . . .

From an Access or VB front end, it never is, so far as I can see.

Quote:
> . . . I think that JET is better engineered that ADO,
>particularly for use with ISAM data sources, and it is definitely
>not slower than ADO.  In ADO, there are always 5 ways to do any
>task, and many of them won't work.

But ADO also is the preferred tool when working with Jet from ASP,
I think, precisely because the context in which ASP is going to be
used is going to work better with a server-optimized abstraction
layer.

Quote:
>>Granted, ADO does have important features that DAO lacks, but
>>those are all designed for use with server back ends, so none of
>>them are relevant to interfacing with Jet data.

>I agree.  I do like disconnected recordsets - a cool, but not
>compelling feature.

I can't see any scenario where that would make it worth using ADO
with Jet from an Access front end.

One clarification: when I say "Access front end" I mean an MDB/MDE,
 not an ADP. So far as I can tell, ADPs are not Access in any
significant meaning of the term. They work only with SQL Server,
and so I think they should be thought of as a part of SQL Server
that happens to be provided with retail Access.

Quote:
>>I can't come up with any reason for ever choosing ADO for use in
>>an Access or VB front end when your back end is Jet. Microsoft's
>>promotion of ADO in that scenario was always, and still is,
>>brain-dead stupid.

>It depends on your perspective.  I would say unnecessary rather
>than stupid.  Microsoft wants to get everyone used to using MS SQL
>Server so they can sell more copies of MS SQL Server regardless of
>whether it's really the best tool for a given job.

And that's {*filter*}y stupid from every standpoint except Microsoft's.

Quote:
>In the latest versions of ADO and JET, the kinks are starting to
>get worked out, and JET has been enhanced to support some more
>ANSI-like syntax making it easier to write JET ADO code that's
>portable to SQL Server.

Jet has been enhanced? Are you sure it's not the Jet ADO provider
that's been enhanced?

Quote:
>I would be more comfortable with all of this if ADO didn't seem to
>be so strangely designed.  It seems to have been more thrown
>together than well thought out.  JET error handling is still more
>useful than ADO, and I include client/server applications in that
>statement.

ADO's purpose is to provide a uniform interface to every data
source there could ever be, from mildly structured text files, to
XML, to Jet, to SQL Server, and to any database server. That's a
tall order, and it's pretty clear that huge swaths of ADO will be
specific to the particular data source type you're dealing with.

As much as I badmouth ADO in the context of Access, I still think
it was the right thing for Microsoft to do (i.e., to create a
replacement for ODBC as a uniform data interface), and I think they
did a pretty good job.

The problem with creating a decent error structure in an
abstraction layer like ADO is that it's not necessarily going to
yield any useful information from the other side of the abstraction
layer. Yes, it could report on itself, but it won't necessarily be
able to get useful error codes from data sources that simply don't
provide them.

It's a daunting task, and in a few years, ADO will be as ubiquitous
as ODBC.

--
David W. Fenton                         http://www.*-*-*.com/ ~dfenton
dfenton at bway dot net                 http://www.*-*-*.com/ ~dfassoc



Sat, 25 Jun 2005 05:46:41 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ADO Recordsets and Forms (ADO vs DAO)

2. Using ADO Recordset with Forms (ADO vs DAO)

3. ADO vs DAO with recordset operations

4. ADO vs. DAO Recordsets

5. opening recordset : DAO vs. ADO

6. a2k, mdb, bound form, dao, recordset, recordset clone, addnew, update, edit, dirty

7. ADO recordset, Form RecordSet Property

8. ADO recordset errors when trying to set to form recordset

9. ADO Recordset bound to Form.Recordset not updatable

10. ADO Recordset bound to Form.Recordset not updatable


 
Powered by phpBB® Forum Software © phpBB Group