Question & Answer
When saving changes to a record in Maximo, if the UPDATE fails to update any rows, Maximo will display this message. The cause is not always another user's activity.
Maximo uses optimistic locking to ensure that two users cannot update the same record without being aware of each other's updates. 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. This ensures that when a record is updated the value of ROWSTAMP changes.
When Maximo updates a record, it references both the table's primary key(s) and the rowstamp value in the where clause. 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. 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. The user must re-query the record in order for Maximo to get the updated value of rowstamp, as well as any other changes.
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.
For version 6 and higher, the message identifier is BMXAA4200E.
Integration Framework Continuous Queue Processing
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. 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.
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. That is normal.
Custom trigger on the table being modified
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. The only message that will return to Maximo will be "zero rows updated".
All custom triggers should be written to raise an exception when one occurs. You do not want a transaction to continue when an error has occurred.
Custom trigger on another table
Maximo may use multiple database connections for some transactions, such as closing a workorder. Thus a trigger on one of the tables will not be able to see that changes made to the other table because they have not yet been committed and were made within a separate session. This can result in errors that cause an update to fail.
Be very careful when writing triggers that modify a table other than the one that fires the trigger. (Triggers that modify tables that are not part of Maximo will not affect Maximo in this fashion.) It is generally better to use custom Java code to change values in the other object rather to change the other table directly.
Custom class processing
A custom class that directly updates a table instead of using a Maximo Business Object to do so, or which instantiates an object for a second time within the same session can possibly update a record before Maximo does so, causing the "Record has been updated by another user" message.
17 June 2018