Ann,

> >What do you mean by "table constraints" ? CHECKs defined at the table

level

> >?
> >I've played with some select-form CHECKs, and it seems they run in the
> >*current* tx context unlike other constraints.
> >
> Sorry, I may have been generalizing without enough information. The
> select form checks should run in system context (my opinion, like
> everything else I write). They were implemented during the years I was
> away from the project and their developer may have decided differently.
> Or may not have thought about the problem. If it were up to me, I'd fix
> that in future versions.

Would be great. Because *supposing* I have to setup integrity rules that
can't be expressed thru regular means (Unique & RI contraints), I'm left
without a 100% safe solution. Am I right ?

BTW, shall I add a request for this (fix) on sourceforge ?


Also, out of curiousity, in the following CHECK

ALTER TABLE TEST_CHK ADD CONSTRAINT CHK_TEST_CHK2 check
(not exists (
select ID
from TEST_CHK T1
where T1.SSN = SSN and T1.PCN= PCN
and T1.START_DATE < END_DATE
and START_DATE < T1.END_DATE
and T1.ID <> ID
));

how can I make FB see in-context variables when they're not prefixed with
"T1." ? I want SSN, PCN, START_DATE and END_DATE to be the pending NEW
values. But apparently, it doesn't work so. FB sees them as if prefixed with
"T1."


Thanks in advance.

--
Jerome