|Subject||Re: [Firebird-Architect] Re: Nulls in CHECK Constraints|
> > Should not we clarify one aspect of cross-table constraints.Could be. Perhaps that is where "assertions" enter the picture,
> (Excellent example deleted. Essentially it's a cross table
> constraint for table T2 depending on values in T1. Changing
> T1 allows the constraint to be violated without error.)
> > Is it up to standard that enabling cross-table check constraints makes
> > it virtually impossible to strictly follow them?
> My understanding - and it's probably very flawed - is that the
> constraint applies to the table on which it is defined and is
> checked after operations on that table. Changes to other
> tables may cause problems, but that's outside the scope of the
as stand alone objects? Perhaps "database constraints"?
> That makes a certain amount of sense. If I have a table T1 and--
> give you read access to it, and you create a table T2 that has
> a constraint based on values in T1, you shouldn't be able to
> constraint my table, should you?
(who like constraints)