1
votes

Recently we upgraded from 2019R1 to 2020 R2 and we did few customizations to JAMS package and we didn't faced any issue in 2019R1 even with our customizations, in this new version 2020 R2 we are facing another process error when releasing Labor Transaction, so I excluded all our extended graph files and verified but still facing same issue.

The error received is "Error: Another process has added the 'AMProdEvnt' record. Your Changes will be lost."

According to the trace, the error appears to be occurring at line 350 of AMReleaseProcess.cs during the Persist(), but the source code does not appear to reference AMProdEvnt or Persist anywhere near line 350.

Final part of the trace:

Error: Another process has added the 'AMProdEvnt' record. Your Changes will be lost.
at PX.Data.PXCache`1.PersistInserted(Object row, Boolean bypassInterceptor)
at PX.Data.PXCache`1.Persist(PXDBOperation operation)
at PX.Data.PXGraph.Persist(Type cacheType, PXDBOperation operation)
at PX.Data.PXGraph.Persist()
at PX.Objects.AM.AMReleaseProcess.cs Ln 350 AMReleaseProcess.Persist()
at PX.Objects.AM.AMReleaseProcess.cs Ln 511 AMReleaseProcess.ReleaseDocProc(AMBatch doc)
at PX.Objects.AM.AMDocumentRelease.cs Ln 49 AMDocumentRelease.ReleaseDoc(List`1 list, Boolean isMassProcess)

Since the trace does not seem to match the source code shipped with build 20.207.0012, I cannot find the problem in the source code. What would cause the record to be added already in the midst of the process that should be performing the actual add of the record?

Here is a screenshot of the trace. We are in - 2020R2 Build -20.207.0012

enter image description here

1
When I look at my CodeRepository on 20.207.0012, the line numbers in the trace do not appear to line up with the code repository file. For instance, line 350 of AMReleaseProcess is if(!UpdateProduction) which seems highly unlikely to throw an error in persist. You might try running a debug or using Request Profiler to look at all the SQL statements being fired. dnSpy is nice for tracing running processes. I don't actually use the Mfg module, so that's all I can share of my observations. @Brendan may be the best resource I know for further help. - Brian Stevens
Thanks for inputs Brain Stevens, will try it and keep you posted. - John
@BrianStevens: the post was correctly closed. Now that the image has been replaced with a text representation of the same, it may reopen. - halfer

1 Answers

1
votes

I checked with Brendan, an Acumatica employee, who advised:

I believe this is just a known issue and upgrading should resolve the issue as well as fixing the line counters for production events (AMProdEvent) by setting max line into the AMProdItem.LineCntrEvent (might be wrong spelling).