Solved

Cannot mark the record as updated because another record with the same key exists in the cache. Contact your Acumatica support provider for the assistance.

  • 6 February 2024
  • 7 replies
  • 226 views

Userlevel 7
Badge +8

Hello all,

I have the below code that works just fine and as expected in 2022R2. I am upgrading this package to 2023R2 and I am getting an error that “Cannot mark the record as updated because another record with the same key exists in the cache. Contact your Acumatica support provider for the assistance.” When I trace on the line that I try “journalGraph.Save.Press();” the problem is caused.

Any idea what is going on or has someone come across the similar issues on upgrade to 2023R2? This is my code without any change from 2022R2 => 2023R2.

        #region Reverse Action & Method
public PXAction<HCLPMWIP> HCLreverse;
[PXUIField(DisplayName = HCLPMMessages.Reverse, MapEnableRights = PXCacheRights.Select, MapViewRights = PXCacheRights.Select)]
[PXButton]

public IEnumerable HCLReverse(PXAdapter adapter)
{
if (IsValidWIPDocument() == true)
{
try
{
JournalEntry journalGraph = PXGraph.CreateInstance<JournalEntry>();
journalGraph.BatchModule.Current = Batch.PK.Find(this, BatchModule.GL, HCLWIPDocument.Current.BatchNbr);

if (journalGraph.BatchModule.Current != null)
{
if (journalGraph.BatchModule.Current.Released != true)
{
journalGraph.BatchModule.Delete(journalGraph.BatchModule.Current);
journalGraph.Save.Press();
}
else
{
throw new PXException(HCLPMMessages.GLBatchIsReleased);
}
}

HCLWIPDocument.Current.Status = HCLPMWIPStatus.OnHold;
HCLWIPDocument.Current.Released = false;
HCLWIPDocument.Current.Module = null;
HCLWIPDocument.Current.RefNbr = null;
HCLWIPDocument.Current.BatchNbr = null;
}

finally
{

HCLWIPDocument.Update(HCLWIPDocument.Current);
Save.Press();
}
}

return adapter.Get();
}
#endregion

 

icon

Best answer by aaghaei 7 February 2024, 08:06

View original

7 replies

Userlevel 7
Badge +8

I am not sure what the hell is happening with 2023R2 but this is what I did and it seems to solve the issue I had after wasting a full day. I replaced the PK.Find method with the Search method to load the current record. basically I replaced this

journalGraph.BatchModule.Current = Batch.PK.Find(this, BatchModule.GL, HCLWIPDocument.Current.BatchNbr);

with this

journalGraph.BatchModule.Current = journalGraph.BatchModule.Search<Batch.module, Batch.batchNbr>(BatchModule.GL, HCLWIPDocument.Current.BatchNbr);

in the above code.

I still do not underestand what have changed in 2023R2 compared to 2022R2 that caused this issue and couldn’t find any release note comment about it.

Badge +11

Glad you got this figured out. This is an excerpt from my personal Acumatica documentation on the page titled “Frequent Time Sinks:”

Objective

load a document in a graph, using graph.Document.Search<key>

Issue

returns objects for the default DocType but returns null for anything else

Cause

the keys are being used incorrectly, which doesn’t correctly pass the DocType parameter to the search

Fix

usually, use 'RefNbr' as the key and first parameter and pass DocType as second optional parameter
paycheckGraph.Document.Search<PRPayment.refNbr>(item.RefNbr, item.DocType);

Userlevel 7
Badge +8

Thanks for chiming in @darylbowman. When calling the Search function I suggest including ALL key fields in “<>” separated with “,” and passing the key values in “()” appended for extra search parameters to avoid inaccurate result returned. In my case both PK. Find and Search are returning the correct record but somehow the Delete action doesn’t like the PK.Find method.

Badge +11

That’s fine as a general rule, but specifically for Document screens (ie SOOrder, POOrder, ARInvoice) doing Search<docType, refNbr>(item.DocType, item.RefNbr) will NOT work. It’s because Search is a function of the View, and it works according to how the View is written (or something like that). More info here.

Userlevel 7
Badge +8

Thanks @darylbowman for the link and explanation. This makes me more confused 🫤. I mostly work with construction vertical objects and I can give you an example that works exact opposite of just passing one parameter that I learned it hard way as well. If in Acumatica Cost Projection Entry you try to locate the desired projection and if you have the same projection ID for two different projects, and if you do not pass both keys then system will always return the first Project Revision. I.e. project A and B both have Rev1 (key is A, Rev1 and B, Rev1) if I do <revisionID>(Rev1, B) or <projectID>(B, Rev1) the result anyways will be A, Rev1 but if I do <projectID, revisionID>(B, Rev1) it returns the correct result. I think it is more to this misterious Search than outlining a hard rule for it though. The good thing is hope fully it’s either/or if time to time someone in Acu dev team doesn’t decide to make a change that can cause unexpected consequences like what happened to me and resulted I start this thread.

Userlevel 6
Badge +3

@aaghaei I had the exact same issue with a different PK.Find.

//InventoryItem inventoryItem = InventoryItem.PK.Find(Base, row.InventoryID);

InventoryItem inventoryItem = SelectFrom<InventoryItem>.Where<InventoryItem.inventoryID.IsEqual<@P.AsInt>>

.View.Select(Base, row.InventoryID);
 

I had to get rid of the PK.Find and do it with BQL.  It compiles just fine as it was, but threw an error at runtime.  Wow.  I too spent about a day figuring that out.

 

Userlevel 7
Badge +8

Glad you made it work FINALLY 😂

In 2023 I see Acumatica has added an extra argument “PKFindOption” to the PK definition of the DACs and I am guessing it’s what messes with how platform behaves.

Reply


About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved