Hi Claudio,

> > What do DEFERRED constraints actually mean? When DO they start
> > checking? And when don't they?
>
> The current constraint implementation is fired when a record is inserted,
> updated or deleted. There are some relationships that may need data in

more

> than one table to be valid. Currently, these cases can't be validated or
> they would be rejected. Triggers aren't a reliable solution for this task

in

> multi-user environments.

Which reminds me - Oracle also has triggers that fire after each statement
instead of each row... Also quite a nice addition :)

> AFAIK, Sybase allows deferred constraints. One changed table as seen alone
> may be inconsistent at the time the operations over it are being done, but
> if the change to all tables is analyzed after several operations, we can
> find that we got the equivalent of an OODBMS' state change for all

involved

> objects, where the configuration as a whole went from one consistent state
> through another consistent state, even if there were intermediate steps of
> inconsistency. For a relational engine, this means all the DEFERRED
> constraints must be checked at commit time. David's first example can be
> assimilated to the second, if you commmit after a single statement that
> produces multiple changes in a table.

Any idea if this would be possible, easily? Are DEFERRED constraints
used a lot? ( I can image this for database wide constraints instead of
table wide)


With regards,

Martijn Tonies
Database Workbench - the developer tool for InterBase & Firebird
Upscene Productions
http://www.upscene.com

See you at the First European Firebird Conference in May in Fulda, Germany
http://www.firebird-conference.com