|Subject||Re: [Firebird-Architect] Multi Connection meta data update|
> >See above. IMO, the proper (more or less) solution would be to justIt might be me ... but: what changes need to be propagated
> >exclusively lock both tables being affected.
> I think that won't work in Classic since processes may
> have requests that are compiled but not active. They
> must be notified so they can recompile their requests
> to include the new constraint. My model would be an
> abstract existence lock which is acquired when a table is
> referenced in a compiled request and released when the
> request is released. The index header page serves that
> purpose for indexes. A similar lock could be used on
> procedures to insure that changes to them are propagated
> as well.
to a procedure or compiled request?
New indices? Why?
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL