I have a Maximo application that has a SQL backend and I restored a table that contained a rowstamp from a previous day. Now, none of the screens that reference that table will work correctly and say that another user is updating the table.
Here is what the makers of the software have to say. I ran update stats and rebuild indexes on all tables.
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 with the next value of the MAXSEQ sequence by a trigger on Oracle. 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 status "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.