You’re offline. This is a read only version of the page.
Hello Everyone,
We are based in the UK and we are new users of Business Central after having recently migrated over from NAV.
Our users are complaining that they are constantly receiving the message 'The operation could not complete because a record in the G/L Entry table was locked by another user. Please retry the activity.' and they are having to wait a long time (sometimes up to a minute) before they are then able to post. We do raise quite large sales orders with lots of lines (some times in the region of 30/40 lines), however I wouldn't have thought this should result in such a long lock down, it certainly didn't take that long in NAV.
Does anybody have any idea what might be causing the issue or could anybody offer some advice?
Thanks...
Thank you for your response! We did check to make sure that the auto cost adjustment was set to NEVER, and that has been the case since our go live. Thanks for the heads up on the customizations. I will make sure that our team reviews those in depth. I will also provide the link that you provided to our dev team. If we find anything else helpful, I will report back here! Thanks!
Hi AngelaKD,
Can you review my first post and let me know if you have 'Auto Cost Adjustment' = ALWAYS? Depending on a number of variables and setup configurations, that can really have an impact on performance, hence the locking/blocking errors.
If it is ALWAYS, set it to NEVER and see if that makes any difference. When this is set to NEVER, you'll need to run the Adjust Cost process manually or nightly batch Job via Job Queue, but will need to ask your partner more on that.
If that is not the case, or that does not help, then many times it can be Custom Code that is causing inefficiencies, which lead to the problem.
Also, for anyone reading this post, making an assumption that Customizations/Extensions on one version will work perfectly and exactly the same on a newer upgraded version can lead one down the wrong path in troubleshooting. I've seen many instances where this point holds to be true and can be the cause of locking/blocking. It is good to be mindful of this :)
If 'Auto Cost Adjustment' is not the cause, and you are not able to find anything around Customizations, then regarding to known BC14 fixes, you can sift through the CU links contained below to see if anything stands out.
Thank you,
Bryan
I'm curious if you ever found a solution to this. We are using BC14 because we have an ISV that hasn't converted to extensions yet, so we had to choose that version. Our users can't run their normal daily tasks because of locking and blocking errors. We were doing fine in NAV2013, but this version is not working well for us. I'm hoping that you were able to find some help!
Okay
Thanks for your response Bryan. Unfortunately I'm not convinced this is the issue. We've checked the instance of NAV we upgraded from, here's a screengrab of the settings taken from that:
So it was set to ALWAYS in NAV and we didn't experience this issue. Obviously all our data, the number of users and processes are identical. I find it hard to believe that we would need to make what I would deem a retrograde step by changing this setting when we've 'upgraded' to Business Central. I appreciate that this running on Sass and not on prem however it just doesn't sound correct to me.
I think the issue is probably around a setup/posting issue but am not convinced this is it.
IF you have Automatic Cost Adjustment = ALWAYS within Inventory setup, that is more than likely the cause of the problem. The Adjust Cost process locks tables as it is running through it's calculations and adjustments...it needs to lock tables. The setting of ALWAYS is Not for everyone...many variables go into the decision on whether or not a company can have costs adjust on the fly, during posting. If it is already set to ALWAYS, set it to NEVER and see if that makes a difference. Then they will need to run Adjust Cost manually, while nobody is posting, or in nightly job queue….which many people do.
I have made a sandbox, on the spring release, you can already do this, now with demo data. Its working faster :)
I've seen this error raised a few times and it is a pain. Happy to have a discussion with you on what may be causing this, although a good start would be to look into what version of Business Central you're running. If you're not yet on the Spring release, you may see improvements after the update.
I'll send you a message so you can contact me directly.
Well they are running on BC Sass not on prim, and its well known thats the Sass can be slow… We all hope for the best when upgrading to Spring version
I would not expect this to occur from a 2018 to BC upgrade, and certainly not with SO's 40 lines deep. It does not sound like it is something standard causing this. Good luck.
Share
Report
All responses (
Answers (
10
