>
> > > If I'm right, does this have a reason?
> >
> > Some things are bigger than transactions, indexes are global for
> > instance. What about constraints? If you were to add a unique
> > constraint, and another user is active, should they be allowed to add
> > a duplicate to the table before you commit? What about foreign keys?
> > All of these items are new restrictions other transactions need to
> > rely on.
>
> Now it's getting a little religious: "There are bigger things in life,
> my son..." :-)

Not really what I was saying.

What I was saying is that certain objects within the database are
transaction independent. Generators, indexes and constraints are three
examples.

You can't create an index that is not visible to other transactions,
nor can you drop a table etc and maintain isolation with other
transactions, it is a bit of a strange request.

Don't hear me say that there is no case where it would be useful to be
able to run an entire upgrade script in a single transaction. On many
times I would have found this useful. I am saying that you can't do it
in Firebird 1.5 if your script contains both DDL and then DML.

> The problem you describe is one you are bound to have anyway unless you
> have exclusive access.

Unlike some other databases, you do not need exclusive access to
backup the database.

> If you don't, the problem cannot be fixed by the
> above mentioned rule. You always have one moment in time when the new
> database object comes into existence, regardless if it's the moment of
> committing the creation or the moment of creating it. So, I still don't
> see the necessity of the rule.
>
> > General running of your system should not require DDL changes,
> > certainly they may be required if a fix or enhancement is made, so
> > this approach should work fine.
>
> I was talking about enhancements. I have several hundred customers

using

> my client application and its database, and if there is a new feature
> (and sometimes this goes along with creating new tables and
> constraints), all of them must have their databases updated. It

would be

> nice if I could pack the whole updating process into one transaction

and

> afterwards have either the older version (in case of an error) or the
> newer version, but not something inbetween (e.g. the table has been
> created, but the foreign keys haven't been applied etc.).
>

The only way you can do this is to maintain a back-out script to any
upgrade.

Adam