Skip to main content
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.


aaghaei
Captain II
Forum|alt.badge.img+10

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

 

Best answer by aaghaei

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.

View original
Did this topic help you find an answer to your question?

7 replies

aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • Answer
  • February 7, 2024

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.


darylbowman
Captain II
Forum|alt.badge.img+13

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);


aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • February 7, 2024

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.


darylbowman
Captain II
Forum|alt.badge.img+13

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.


aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • February 7, 2024

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.


Joe Schmucker
Captain II
Forum|alt.badge.img+2

@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.

 


aaghaei
Captain II
Forum|alt.badge.img+10
  • Author
  • Captain II
  • 1203 replies
  • March 14, 2024

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


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings