> >See above. IMO, the proper (more or less) solution would be to just
> >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.

It might be me ... but: what changes need to be propagated
to a procedure or compiled request?

New indices? Why?

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com