If there is a custom trigger on the table and the trigger does not have an exception handler that raises exceptions back to Maximo, then any errors in trigger execution will cause the update statement to fail and be rolled back. That is normal.Ĭustom trigger on the table being modified This often results in these errors appearing in the log, but no evidence of error XML or no transactions stuck in Message Reprocessing when the retry succeeded. As long as the continuous queue has been setup to retry errors and also has an exception destination queue defined, the failing transactions will succeed on a subsequent retry. If you process transactions through the continuous queue and send in multiple transactions which affect the same parent record or same set of records, such as multiple partial receipts against the same PO Line or multiple child workorder updates with the same parent workorder, then this error may occur. Integration Framework Continuous Queue Processing Since Maximo always interprets the result "Zero rows updated" to mean that the rowstamp has changed, you may see the "Record has been updated by another user" message when no other user is involved.įor version 6 and higher, the message identifier is BMXAA4200E. The user must re-query the record in order for Maximo to get the updated value of rowstamp, as well as any other changes. If this occurs, Maximo sees that there were zero rows updated by the SQL statement and displays the "Record has been updated by another user" message.
Since the rowstamp value changes each time a record is updated, this mechanism ensures that an update will fail if the record has been modified since it was first queried. When Maximo updates a record, it references both the table's primary key(s) and the rowstamp value in the where clause. This ensures that when a record is updated the value of ROWSTAMP changes.
Each Maximo table has a column named ROWSTAMP which is set to a TIMESTAMP datatype on SQL Server or is populated from a sequence by trigger on Oracle and DB2. Maximo uses optimistic locking to ensure that two users cannot update the same record without being aware of each other's updates.