I'm trying to write a trigger to be used as the
UPDATE, INSERT, and DELETE triggers on a particular
table.  This table is a detail table, and whenever any
of the actions listed are performed I want to update
the EDITEDBY and EDITEDON fields of the header table.

The problem is that R:Base seems to populate different
SYS_ cursors depending on what action is taking place.

When UPDATING, both SYS_OLD and SYS_NEW seem to exist.
 When INSERTING only SYS_NEW exists.  When DELETEING
only SYS_OLD exists.

I understand the logic of this, since in the case of
an INSERT there really isn't an old version of the
row, and in the case of a DELETE there really isn't a
new version of the row.

Unfortunately, this makes it difficult and less
efficient to write that TRIGGER code.  I have to check
both cursors to get my key value to use in the UPDATE
back to the header table.  Furthermore, the failed
checks generate error codes, and if the Trigger has
been executed from, say, an INSERT statement, the
error code is returned by the INSERT statement and
makes it appear as if the INSERT failed.

To get around this problem (without having to write
and maintain three copies of the Trigger) I either
need to figure out what _kind_ of trigger I'm in, or
else R:Base would need to populate both the SYS_OLD
and SYS_NEW triggers for INSERTs and DELETEs.

Anyone have any experience with this?  Any
suggestions?
--
Larry

Reply via email to