Re: Design question

I think almost certainly that there are aspects of SQL DDL that cannot
be performed using ADO, since an ADO connection infers a connection to a
database and some operations that modify a database require that there
are no extant connections to it. Query Analyser, I believe, uses the
ODBC API rather than ADO or OLEDB, as does ISQL/OSQL.

If you really want to use ADO (cause it sure is a whole lot easier :-),
it may be possible to performs these tasks, by establishing a connection
to the "master" database instead of the one you want to modify, it's
worth a shot!

Regards,
Phil Allan-Harding.

Graphicboost Development
Tel: +44(0) 161 980 4136
Mobile: +44(0) 7778 561119
Email:  <mailto:[email protected]> [email protected]
Web:  <http://www.graphicboost.com/> http://www.graphicboost.com

-----Original Message-----
From: Gautama, Damon [mailto:[email protected]]
Sent: Wednesday, 03 July 2002 22:43
Subject: Re: Design question



Thanks for your response, Phil. I looked into isql/osql a bit, and
decided it would be easier to do the work through ADO. That was until
today when I realized that I may have been misunderstanding things. I
have been working under an assumption that I am now thinking might be
errant. Can ADO's Command->Execute process any script that can run in
Query Analyzer?

Thanks again,
damon

-----Original Message-----
From: Phillip Allan-Harding [mailto:[email protected]]
Sent: Thursday, June 27, 2002 5:33 AM
To: [email protected]
Subject: Re: [OLEDB_DEV] Design question
Importance: High


I think the design concept is ok, however, personally I'd favour using
SQLDMO with a VB frontend, or if your in the .NET world a C# frontend.

SQLDMO is designed for database DDL work, however if you need to support

Oracle also, SQLDMO isn't  going to be much use. An alternative would be

to use the isql/osql command line tools, and the equivilent Oracle tools

to run script batches, shelled from your application. The scripts could
be created as temporary files from you apps script resources.

Regards,
Phil Allan-Harding.

Graphicboost Development
Tel: +44(0) 161 980 4136
Mobile: +44(0) 7778 561119
Email: [email protected]
Web: http://www.graphicboost.com

-----Original Message-----
From: Gautama, Damon [mailto:[email protected]]
Sent: Wednesday, 26 June 2002 16:40
Subject: Design question


Hello,
I am working on an application suite that is largely based on a database

(currently SQL Server, soon to add Oracle). Their current schema update
mechanism is to send scripts to their clients to run through Query
Analyzer, and they are hoping for a better approach. My experience is
C++/COM and very light on DB work, so I want to run this approach by
more experienced eyes before I officially propose it.
In the upgrade application, all of the scripts will be stored as
resource strings, making them difficult to alter (read: mess up). The
application will read the current state of the db (a few tables have
version info). If there are any available upgrade routes, they will be
presented to the user. When the user says go, we make sure the db isn't
open, then open a local transaction. All of the relevant upgrade scripts

will be run in the single local transaction, then we will Commit or
Abort depending on the outcome.
Does this sound like the way to go? Are there more effective ways to
accomplish this that I'm not thinking of?
Thanks for any information/advice you can offer.
damon

You can read messages from the OLEDB_DEV archive, unsubscribe from
OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.


You can read messages from the OLEDB_DEV archive, unsubscribe from
OLEDB_DEV, or subscribe to other DevelopMentor lists at
http://discuss.develop.com.


You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.