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.