"Claudio Valderrama C." <cvalde@...> wrote in message news:...

> ""Nico Callewaert"" <ncw@...> wrote in message
> news:CGEMLAHIJBEHDEAMDDMDIEBCCBAA.ncw@......
> > Hi,
> >
> > I have several things to check before a user is allowed to post the
> record.
> > Is it good to do all the check's in 1 single check constraint ? Or
> better
> > seperate it in single constraints ?
> >
> > I defined it like this :
>
> I don't see great difference in having them separately other than being

able

> to drop each one separately. Are you implementing foreign keys in code
> instead of in a FK declaration?
>
>
> > What is the difference between a trigger and such a check constraint,
> > because when I look in IBWISQL, for every check constraint, there is a
> > before insert and a before update trigger defined.
>
> I never inteded to provide high level view of objects in IB_WISQL. Maybe I
> should put an indication in such tab. When you create a check constraint,
> the server must create code. Where does the code go? Obviously, to the two
> instances where it should be run before allowing data: before insert and
> before update. So, the server keeps the constraint definition for your

eyes,

> but the implementation is two triggers that basically do the same: test

the

> value of SomeField in an internal trigger, where SomeField is the field

you

> are protecting with your table-level constraint.
>
> Create the check constraint and let the server fill in the system tables.
> Those internal triggers are managed by IB automagically. However, I have a
> db where one of those pair lost the connection to the parent table and now
> they appear as independent triggers. You can recognize immediately this as
> corruption, since normal triggers have a BEGIN, not a CHECK in the source
> code of them. In your case, all is well. You're contemplating an
> implementation detail.
>
> Disclaimer: IB_WISQL was originally devised by Jason Wharton. I've

enhanced

> it since then. I do not claim ownership or full authorship.
>
> C.
>
>