DAO to ADO Conversion - Newbie HELP

[Pete]

I have a routine written in DAO that I want to convert to ADO. Please
look at the following code and provide some assistance.

Dim daoQueryDef As DAO.QueryDef

Set daoQueryDef = CurrentDb.QueryDefs("qryDynamicSQL")
daoQueryDef.SQL = Me.QueryString.Value
DoCmd.OpenQuery "qryDynamicSQL", acViewNormal, acReadOnly


Me.QueryString.value contains the SQL string to be displayed
qryDynamicSQL is a skeleton query.

The results of the above will display a table showing the results of
the SQL string.

 

[Allen Browne]

If you use ADOX, you could change the CommandText of the View or Procedure.

Why though? Seems like a long way around when DAO is the native language
Access itself uses, and you could just use this one line:
dbEngine(0)(0).QueryDefs("qryDynamicSQL").SQL = Me.QueryString.Value

 

[Pete]

I am just trying to eliminate all references to DAO in the program. Is
this a bad goal?

 

[Brendan Reynolds]

Unless you have a very specific reason for doing so, it's probably not a
productive use of your time.

Around about the year 2000 or so, ADO was being hyped as 'the future of data
access technology', and people were joking about 'DAO is DOA'. But today
'classic' ADO (while still supported) is no longer being further developed,
having been replaced by ADO.NET, which has little in common with 'classic'
ADO other than three letters in its name and is not supported by any version
of Access.

So, if you were planning on converting to ADO because you've been reading
one of those 'DAO is dead, ADO is the future' articles, I wouldn't bother.
Of course, you may have another reason?

 

[Craig Alexander Morrison]

Yes!

ADO is being discontinued.

 

[Pete]

So the bottom line is do not convert and existing DAO app to ADO.
Correct?

 

[Brendan Reynolds]

Unless you have a good reason to do so - and I can't think of one at the
moment.

 

[Pete]

Thanks.

 

[(PeteCresswell)]

Per Pete:

I am just trying to eliminate all references to DAO in the program. Is
this a bad goal?

I'd say it is if the back end is a JET DB.

 

[Danny J. Lesandrini]

Huh?

Maybe I've been asleep or maybe this is sarcasim, but am
I to believe that ADO support is going away?

 

[Pete]

What if I split the database and move the tables to a server on another
net, or I convert the app to use msSQL?

 

[Craig Alexander Morrison]

ADO.NET will be replacing ADO.

I am sure that ADO will be supported in the meantime.

For all new projects I would recommend using MDB rather than ADP and use DAO
rather than ADO.

Don't take my word for it check out recent posts from Mary Chipman of
Microsoft over the last 6 months.

 

[Danny J. Lesandrini]

Mary Chipman is a Microsoft dude? I thought she was independent.

btw, what is the English (American) translation/equivilent of Slainte

 

[Craig Alexander Morrison]

Mary Chipman is a Microsoft dude? I thought she was independent.

She went over to the dark side (vbg) a couple of years ago, so did MichKa.

btw, what is the English (American) translation/equivilent of Slainte

From the Gaelic it means, essentially, "good health and best wishes" or
"cheers".

--
Slainte

Craig Alexander Morrison
Crawbridge Data (Scotland) Limited

 

[Danny J. Lesandrini]

Pow!

It's like I've been in some kind of time capsule. MichKa went over too?
I vaguely remember something about him being involved with the Access 97
project, but I thought he and MS got along like an old married couple ... poorly.

What's he working on there? Anybody know?

 

[Douglas J. Steele]

MichKa's a Technical Lead for Globalization Infrastucture, Font and Tools.
He's been there since August of 2002. His blog's
http://blogs.msdn.com/michkap/

(I had dinner with him last time I was in Redmond, and he seems pretty happy
there)

I didn't know, however, about Mary.

 

[(PeteCresswell)]

Per Pete:

What if I split the database and move the tables to a server on another
net, or I convert the app to use msSQL?

If you're talking Client/Server, I'd say there are some arguments for going to
something else besides DAO links.

I've heard people report that they went to C/S keeping DAO links and had no
problems at all.

Personally, I've converted a couple of apps in which performance went down the
tubes when we stayed with DAO links.

With a C/S back end, it seems to me like your real gains are in writing stored
procedures to do the heavy lifting and, for forms that have many subforms,
stacking all the sub-datasets in a single stream so there's only one trip to the
server.

If you're going to C/S, I'd advise just sticking with DAO until you see a
performance problem.


For me, a split application is a given. I wouldn't even think of putting the
data and the front end in one .MDB. If you're talking about putting the back
end of a split application somewhere far, far away - like at the other end of a
dialup connection - then, as far as I know, a Client/Server back end is a given.
..MDB just won't do the job.