Subject | Re: Metadata update |
---|---|
Author | Svein Erling Tysvær |
Post date | 2005-09-07T11:32:39Z |
--- In firebird-support@yahoogroups.com, "Carlos Macao" wrote:
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
rollback.
Set
> I was trying to build an automated application install which amongI doubt it, but does that really matter? I suppose it could do if you
> 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?
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
rollback.
Set