Subject Re: Metadata update
Author Svein Erling Tysvær
--- In, "Carlos Macao" wrote:
> I was trying to build an automated application install which among
> other tasks tries to update DB metadata with a bunch of scripts. I
> was looking for a solution which could protect all this operations
> under a transaction umbrella with a unique and final commit or
> rollback conditioned by the install success.
> The problem has to do with compiled statements which depend on new
> fresh metadata entries (like inserting a new SP which depends on a
> new Table, all in the same script using only a final commit).
> Is there any way to achieve that with this Firebird limitation?

I doubt it, but does that really matter? I suppose it could do if you
added something to an existing table whilst people were updating it,
but you should anyway be very careful about doing DDL (data
definition) on a database when others do DML (manipulate data)
simultaneously. As for new tables/stored procedures, I don't think
having to commit should matter at all, users (excepting the one you
always can trust not to do anything silly: SYSDBA) doesn't get access
to any new tables until a GRANT is issued anyway, and you could always
do this as the last step. For rollback? Well, you've already got your
create/alter statements, so it shouldn't be too difficult to change
things back to the original state - simply by analysing what you've
done. Though I admit it is a bit more complicated than a simple