> But I'm always suspicious about real world and clients.
> We have 5000 clients who can be qualified as "stupid users" and
> the scripting is done automatically.
> There may always be some case where somehow some update doesn't
> work.

Then arrange to log any errors that occur, so the problems can be
reviewed later:

procedure xxxx.DoScriptError(Sender: TObject;
const ERRCODE: Integer; ErrorMessage, ErrorCodes: TStringList;
const SQLCODE: Integer; SQLMessage, SQL: TStringList;
var RaiseException: Boolean);
begin
WriteLog(...);
// if you want to try and run the rest of the script regardless
// of any errors that may occur then also have something like
if RaiseException then
begin
if (option_that_says_to_ignore_errors) then
RaiseException := false;
else
WriteLog(script_aborted);
end;
end;

Whether you write the log to a normal file or to a table in the
database is up to your requirements.


A couple of other points to consider...

If you commit a series of individual changes to a table then you
will increment the version number on that table each time. Whereas
if you script all the changes at once and then commit the version
number is incremented only once (or that is my understanding). So
you may need to be careful that you dont exceed the version limit
of 255, and may be best advised to backup/restore to reset the
version after the upgrade has been successful.

You can generally avoid needing to commit every statement if you
get the order of your script correct - but getting it correct can
be a lot of hard work.

If you have not done so already, you may like to take a look at my
DBak application, the help file that comes with the precompiled
executables explains how it could be used to automate the upgrade
process. http://www.telesiscomputing.com.au/dbk.htm
(Or if you prefer you can achieve something similar yourself using
the metdata extract component in IBO with your own transfer
processing.)


HTH

--
Geoff Worboys
Telesis Computing