Skip to main content
Question

Differentiating a jBASE record create within a trigger

  • March 9, 2026
  • 2 replies
  • 20 views

Paul Bauman

I am looking for a way to differentiate a record create (or insert if you will) from a record update within a trigger.  I am not seeing anything that would allow me to do this easily.   My use case is to send out an event on a record create and a different event on a record update.  I want this to happen only after a successful write.

I can see on a pre-write how I could see if the record exists already or not, but then if the write should fail, I would have sent an event for the create or the update that is out of sync with the state of my database.  I would like to avoid having 2 events sent on a create (one pre-write detecting a create and one post-write for an update).

It would seem to be an important piece of metadata that should be available to the trigger as to whether or not this record had to (or will) be created by the write.

Has anyone else already come up with an elegant solution or can point out the obvious thing I am missing?

2 replies

Paul Bauman
  • Author
  • New Participant
  • March 11, 2026

I should add some more detail.

 

I tested the userrc parameter to see if I could load that with a positive number in prewrite and be able to see it at post write and that did not appear to work.  So I can not set a “new” flag for use at postwrite.

I also have realized that since I do not seem to have access to the before write record, I can’t limit actions to only “on change”.  I would have thought that the trigger api would include the initial state of the record as well as the current in order to leverage activities like change data capture or eventing.


Paul Bauman
  • Author
  • New Participant
  • March 12, 2026

For those interested, lacking the state of the pre-action record, I have opted to add some overhead and to read the record myself and to use named commons to store the contents of the record and its ID at the PREWRITE (thanks for the reminder to Bruce Decker at Rocket).  Then at POSTWRITE I will compare the named commons stored information to the POSTWRITE information to determine a CREATE, a CHANGE, or a SAVE without change and take the appropriate action. I did this same thing with UniVerse using their index hooks to build “lightweight triggers” there.