On Tuesday 2002-02-12 at 14:45:06 -0000, Jason Chapman (JAC2) wrote:

> ""David K. Trudgett"" <dkt@...> wrote in message
> news:20020212090833.C9371@......
> > On Monday 2002-02-11 at 09:13:48 -0000, Jason Chapman (JAC2) wrote:
> > > if (old.fld is null and new.fld is not null) or
> > > (old.fld is not null and new.fld is null) or
> > > (old.fld <> new.fld) then
> > > begin
> > > EXECUTE PROCEDURE Audit_The_Change(parameters, ...);
> > > end
> >
> > The third condition will be true when OLD and NEW are both NULL, but I
> > don't want to log that case.
> Are you sure, I thought null any_binary_op null => null which is
> interpreted as false in a conditional.

No, I'm not very sure. I haven't tested it yet. My reasoning was along
the lines that "x <> y" is equivalent to "not (x = y)", and "not (null
= null)" is "not (false)", which is "true". The reasoning may well be
spurious, of course, for mysterious reasons known only to the SQL
committee(s). ;-)

>
> Your thing about after_update, we always put ours at a set position (1000)
> therefore always fire last in our db's.

I didn't know about that feature (or forgotten it, more likely). Thanks.


David Trudgett