Another process has added/updated/deleted the ‘{0}’ record. Your changes will be lost.

As Acumatica updates records one by one it expects that sql server returns also one record. Number of records affected will be provided by ASO.Net classes:

int rowcount = command.ExecuteNonQuery()

Our error will be thrown by Acumatica if rowcount is zero. Potential reasons for this error usually:

• Record was really delete/changed before Acumatica wanted to commit update. For example, it may be done by another user or even your code previously.
• Where statement was created incorrectly, and Acumatica cannot find any record for update
• Key of the record was changed before you have committed your changes.

Timestamp
Acumatica uses timestamp as part of positive locking methodology of using shared records in concurrent environment. Timestamp is basically a date and time flag when this record was last changed. To do this Acumatica selects the timestamp when it reads a record and keeps it in memory. During update Acumatica adds validation that Timestamp isn’t changes since record was read.

update GLSetup setPostClosedPeriods = 0
where CompanyID = 2
       and tstamp <=0x00000000000F6959

Each time you update record timestamp will be changed and will be bigger than previous version. In MS Sql server timestamp is special data type that is managed by SQL Server. In My SQL timestamp is simple a datetime type that keeps time of record modifications.

During insert/update/delete operations Acumatica will check timestamp and may not find the record the same way as it was described in previous part as update will return zero records.

In this example record will not be updated if the version is changed.

The key reasons why it may happened:

• Another user or process really have changed this record
• You have saved this record twice in your code
• PXGraph stores wrong or old timestamp for comparison. Graph reads and stores timestamp during data read and it may be changed manually or due to some triggers.

How to diagnose it?
So based on the description before you understand that problem mostly happens on SQL server side, but it is validated and rises error only on servers side after query execution. So the best way to get the root reason is to check SQL statement. To find SQL statement you can use

• Acumtica Request Profiler
• SQL Server Profiler

As soon as you get query, copy it and paste to SQL Management studio. Than you need to check where statement and try to execute it. In most cases you will see the error and will be able to fix it.

If you cannot reproduce error after save, than it might be flow related. Than I recommend to add event handler to RowPersisting (that occurs right before save) and put break-point there.  Try to execute your statement as soon as code hits your break-point.
Please note that some of the data might not be committed right now as transaction is still open. To read data from transaction you can use NOLOCK directive of SQL server.

select * from NumberingSequence with (nolock)

This directive will ignore transaction isolation level and read uncommitted data as well.

Other common issues that you can check in the code:

• Make sure you have correct keys define in DAC
• Make sure you don’t save record twice
• If you have any database identity columns make sure that appropriate attributes defined in DAC
• If you have master-details relationship make sure that child class has PXDBDefault attribute assigned to liked keys. This may be a problem when child record is saved with wrong key
• If you have auto-generated key make sure key is updated properly before saving.

Have a fast troubleshooting!