Suspended transactions & triggers

We found a spot where we do something like

QUERY ([table];[table]field=“XXX”)
…change some fields to provide unique values
SAVE RECORD([table])

Keep in mind the record we get from the query may or may not be in the transaction that we are suspending.

As expected, when we DUPLICATE RECORD, the record number changes to -3 and the debugger shows Records in selection ([table]) = 1.

The mind blowing part that we can’t figure out is that when we hit the SAVE RECORD call
- the record number stays at -3 instead of becoming a real record
- Records in selection([table]) now shows 0 instead of 1
- the trigger on the table never fired
- OK = 1, implying that the SAVE RECORD call succeeded (even though it never steps into the trigger.

We follow pretty much the same code on another table whose record may or may not be in the suspended transaction and it behaves just fine.

We wrote a ‘wrapper method’ to replace the DUPLICATE RECORD command using ORDA and that works just fine, but we’re uncomfortable using that kind of ''Band-Aid" for this.

We are clueless at this point as to what is going on here.

Anyone have any ideas?


I do not have a definitive answer,

but based on what you describe:

  1. could it be that the record found by QUERY is locked?
  2. could it be that an explicit LOAD RECORD after the QUERY (or an UNLOAD before the QUERY) might make a difference?


We tracked this down Friday waiting for a reply.

Guess #2 seems to fit our experience.

We had to do an explicit LOAD RECORD before calling DUPLICATE RECORD.

Even though 4D seemed to have the record and we could see the record number and contents of the fields, somehow it didn’t really have it.

Totally bizarre.