What does the field Use Legacy G/L Entry Locking actually do in NAV 2013?

Do you or your customers have peak hours when all the sales orders and invoices need to be posted at the same time? Or do you have large numbers of postings that need to be run without blocking other users?” – I loved the way NAV Team introduced new locking functionality of NAV 2013. But they also left a way of using old functionality – by enabling field “Use Legacy G/L Entry Locking” in General Ledger Setup.

The field “Use Legacy G/L Entry Locking” has been around for a long time (since NAV 2013), but it is something I haven’t paid special attention to. The field name sounds menacing, but what does it actually do?

According the documentation, field “Use Legacy G/L Entry Locking

Specifies when G/L Entry table should be locked during sales, purchase and service posting. By default, the check box is cleared to leave the G/L Entry table unlocked at the start of posting. The table remains unlocked until the lock is needed. This can improve performance in multiuser environments.

Sounds good. Now, what does it mean for a developer?

When I want to understand something in more detail, I start by asking – where is it used?

We can see that there is a field in General Ledger Setup, but let’s crawl through the code and learn more.

General Ledger Setup - Use Legacy GL Entry Locking

The field “Use Legacy G/L Entry Locking” is used only in a few places:

  1. OBJECT Table 98 General Ledger Setup, PROCEDURE OptimGLEntLockForMultiuserEnvUse Legacy GL Entry Locking - OptimGLEntLockForMultiuserEnv
  2. OBJECT Table 313 Inventory Setup, Automatic Cost Posting – OnValidateUse Legacy GL Entry Locking - OnValidate
  3. OBJECT Page 118 General Ledger Setup

Nothing ground-breaking yet, let’s continue and have a look at where function OptimGLEntLockForMultiuserEnv is used.

OBJECT Codeunit 80 Sales-Post
LOCAL PROCEDURE LockTables

LOCAL LockTables()
SalesLine.LOCKTABLE;
ItemChargeAssgntSales.LOCKTABLE;
PurchOrderLine.LOCKTABLE;
PurchOrderHeader.LOCKTABLE;
GetGLSetup;
IF NOT GLSetup.OptimGLEntLockForMultiuserEnv THEN BEGIN
GLEntry.LOCKTABLE;
IF GLEntry.FINDLAST THEN;
END;

LOCAL PROCEDURE SortLines

GetGLSetup;
IF GLSetup.OptimGLEntLockForMultiuserEnv THEN
  SalesLine.SETCURRENTKEY("Document Type","Document No.",Type,"No.")
ELSE
  SalesLine.SETCURRENTKEY("Document Type","Document No.","Line No.")

OBJECT Codeunit 90 Purch.-Post
LOCAL PROCEDURE LockTables

PurchLine.LOCKTABLE;
SalesOrderLine.LOCKTABLE;
GetGLSetup;
IF NOT GLSetup.OptimGLEntLockForMultiuserEnv THEN BEGIN
  GLEntry.LOCKTABLE;
  IF GLEntry.FINDLAST THEN;
END;

LOCAL PROCEDURE SortLines

GetGLSetup;
IF GLSetup.OptimGLEntLockForMultiuserEnv THEN
  PurchaseLine.SETCURRENTKEY("Document Type","Document No.",Type,"No.")
ELSE
  PurchaseLine.SETCURRENTKEY("Document Type","Document No.","Line No.");

OBJECT Codeunit 900 Assembly-Post
LOCAL PROCEDURE LockTables

AssemblyLine.LOCKTABLE;
AssemblyHeader.LOCKTABLE;
GetGLSetup;
IF NOT GLSetup.OptimGLEntLockForMultiuserEnv THEN BEGIN
  GLEntry.LOCKTABLE;
  IF GLEntry.FINDLAST THEN;
END;

LOCAL PROCEDURE SortLines

GetGLSetup;
IF GLSetup.OptimGLEntLockForMultiuserEnv THEN
  AssemblyLine.SETCURRENTKEY("Document Type",Type,"No.")
ELSE
  AssemblyLine.SETCURRENTKEY("Document Type","Document No.","Line No.");

LOCAL PROCEDURE SortPostedLines

GetGLSetup;
IF GLSetup.OptimGLEntLockForMultiuserEnv THEN
  PostedAsmLine.SETCURRENTKEY(Type,"No.")
ELSE
  PostedAsmLine.SETCURRENTKEY("Document No.","Line No.");

OBJECT Codeunit 5980 Service-Post
LOCAL PROCEDURE LockTables

ServiceLine.LOCKTABLE;
GLSetup.GET;
IF NOT GLSetup.OptimGLEntLockForMultiuserEnv THEN BEGIN
  GLEntry.LOCKTABLE;
  IF GLEntry.FIND('+') THEN;
END;

OBJECT Codeunit 5988 Serv-Documents Mgt.
LOCAL PROCEDURE SortLines

GLSetup.GET;
IF GLSetup.OptimGLEntLockForMultiuserEnv THEN
  ServLine.SETCURRENTKEY("Document Type","Document No.",Type,"No.")
ELSE
  ServLine.SETCURRENTKEY("Document Type","Document No.","Line No.");

Interesting! According to my understanding, the main difference between using “Use Legacy G/L Entry Locking” and not using it, are these lines:

Use Legacy GL Entry Locking - Main Difference

Which means, if we have a checkmark on “Use Legacy G/L Entry Locking” field, we ask the system to lock the G/L Entry table very early in the posting process. For example, in Codeunit 90, we would be locking G/L Entry table before we even started inserting purchase receipt header, posting receipt, etc. When we don’t have a checkmark, we allow system to decide when the table should be locked (which would happen at the end of the posting process, when table needs to be updated).

According to NAV Team blog, this small change results in:
– “Use Legacy G/L Entry Locking” field ticked (or NAV 2009) – G/L Entry is locked >90% of the time during sales/purchase post
– “Use Legacy G/L Entry Locking” field not ticked (or NAV 2013 and newer) – G/L Entry is locked <10% of the time during sales/purchase post

That is stunning!

Two other differences would be – the way lines are sorted, and how Automatic Cost Posting is being (or not being) run.

Further Reading:

Technorati Tags: , ,

This entry was posted in Dynamics NAV / Navision and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *