Help with converting DAO to ADO

[robert d via AccessMonster.com]

I'm looking at converting DAO to ADO in my app. All of my DAO connections
are of the following structure:

Dim wsName As DAO.Workspace
Dim dbName As DAO.Database
Dim rsName As DAO.Recordset

Set wsName = DBEngine.Worksp aces(0)
Set dbName = wsName.OpenData base(CurrentPro ject.FullName)
Set rsName = dbName.OpenReco rdset("SQL Statement")

I'm a real newbie with ADO and don't feel at all comfortable with it. Now to
convert to ADO, something like:

Dim cnnName As New ADODB.Connectio n
Dim rsName As New ADODB.Recordset

and here's where I start to get confused:

Set cnnName = Application.Cur rentProject.Con nection????
rsName.Open "SQL Statement" ????

Since I have several hundred of these DAO constructs, I'm trying to figure
out if there is a way I could write code to accomplish the conversion.

Thanks for any help.

--
Message posted via AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[CDMAPoster]

Larry Linson wrote:

Jim,

In the development environment which _matters_ to Microsoft, that is DotNet,
they already _HAVE_ given up on classic ADO. Its successor is ADO.NET which
is based on a different object model.

Unless I am wrong, the PDC (Professional Developers Conference) almost
totally emphasizes DotNet and the ADO to which they refer so frequently is
ADO.NET -- not the "classic ADO" to which Lyle's quote refers.

Larry Linson
Microsoft Access MVP

Thanks for the information Larry. Having used classic ADO but not
ADO.NET I was unaware that the object model had changed. Do you know
of a reference that explains the differences between classic ADO and
ADO.NET with emphasis on the "why?" I'll keep that in mind as I
continue to download and view the presentations.

James A. Fortune
CD********@Fort uneJames.com

[Larry Linson]

No, I haven't kept any references / links, Jim. I have not ventured into
actually _doing_ DotNet, just kept up with the environment as it develops.
Visual Studio 2005 is still strongly enterprise-oriented, but with some
improvements for (or concessions to?) the "little guys". I have more hopes,
from what I've seen published about the goals for the next version,
codenamed "Orcas".

The only times I use ADO are when I am working on someone else's database.
But, I have seen enough of both to know that there's some apparently
similarity, and some real differences.

Larry Linson
Microsoft Access MVP
<CD********@For tuneJames.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

Larry Linson wrote:

Jim,

In the development environment which _matters_ to Microsoft, that is
DotNet,
they already _HAVE_ given up on classic ADO. Its successor is ADO.NET
which
is based on a different object model.

Unless I am wrong, the PDC (Professional Developers Conference) almost
totally emphasizes DotNet and the ADO to which they refer so frequently
is
ADO.NET -- not the "classic ADO" to which Lyle's quote refers.

Larry Linson
Microsoft Access MVP

Thanks for the information Larry. Having used classic ADO but not
ADO.NET I was unaware that the object model had changed. Do you know
of a reference that explains the differences between classic ADO and
ADO.NET with emphasis on the "why?" I'll keep that in mind as I
continue to download and view the presentations.

James A. Fortune
CD********@Fort uneJames.com

[CDMAPoster]

CD********@Fort uneJames.com wrote:

Do you know
of a reference that explains the differences between classic ADO and
ADO.NET with emphasis on the "why?" I'll keep that in mind as I
continue to download and view the presentations.

Lyle's reference to MSDN in another thread combined with the hints in
PDC 05 will provide me with enough information to get the "why?" Being
based on XML is a motivation I understand already. I'll try to compare
ADO.NET's DataSet with C#'s IEnumerable to see if the data structure is
moving toward a unified one. It would be interesting to use language
integrated SQL along with WinFS to get the list of files in a directory
directly. It helps that MS doesn't do much randomly. I've got a lot
of thinking to do once I finish wading through all the PDC 05
information.

James A. Fortune
CD********@Fort uneJames.com

Most relational databases are really one-dimensional in a certain
sense. Most schemas use foreign keys to impose a set/subset relation
on data. That relation enforces a hierarchy or tree and constitutes
only one abstract facet of knowledge.