DAO and ADO 1

[bdfigler]

I am trying to automate some boring tasks involving database maintenance at work -- this means programmatically creating (or copy/pasting) tables, forms, queries, reports, etc.

I couldn't figure out how to create tables via automation -- is there a way to do this with ADO?

And I couldn't figure out how to create queries with DAO -- is this possible?

I am trying to avoid creating both ADO and DAO objects in the same procedure because I feel like I shouldn't have to. Am I wrong?

I could use some help here and also possibly a link to good object models for ADO and DAO. Thanks. -Brad

 

[MichaelRed]

I'm no purist, and do not know of any reason to not use the best tool for the task. Of course it MAY be more of a challenge to keep the syntax of the different approaches seperated -mentally- but the overhead of ADO's ODBC wrapper suggests (at least to me) that it be reserved for 'external' data which cannot be linked directly.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[Spellman]

It is possible to create queries or pretty much do anything using DAO and ADO but you should really use oinly one as otherwise you will need to connections to the database which is a bit of a drain. In order to make a table in ADo you could use something like

SQLString = "Select FieldList Into tablename"
conn.execute sqlstring

where conn is your ADo connection. To make a query in DAO is similar. E.G.

dim db as dao.database
dim qd as dao.querydef

set db = workspaces(0).opendatabase(datapath)
set qd = db.createquerydef("MyQuery",SQLString)


this will make a query called Myquery with the relevant sql in the database. I recommend using ADO though since it is a lot faster and more powerful.

 

[MichaelRed]

Hmmmmmmmmmmm,

Faster? I STRONGLY disagree. It MAY not be slower to use ADO in some situations, but it is NOT going to be faster. Every Ms. Doc and the third party references / tutorials overtly state that ADO is an ODBC wrapper and that it's "advantage" is that Ms. is pronoting it as the 'universal' db access method -NOT- that it is faster. Most third party references do note that it is slower.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over