LOCKTABLE

pmrioux · 2013-10-23

Hello everybody!

Quick question for you guys. At the beginning of the "OnInsert" trigger of table Sales Line, we have the following three commands :

KitSalesLine.LOCKTABLE;
DocDim.LOCKTABLE;
LOCKTABLE;

Is that a good idea ?! Are they necessary ?

Regards,

PM

Marije_Brummel · 2013-10-23

Have you googled on LOCKTABLE with NAV?

This is kind of a strange command and started its life in the old Navision Native database.

What it meant in these days was lock the entire table now.

It does no longer mean that.

Nowadays it means, "whatever rows you read in the table, lock those".

So the statement should be renamed by Microsoft to LOCKROWS

And yes, it is probably a good idea.

Andwian · 2013-10-29

What if we do not use LOCKTABLE?
Is it dangerous?
Can it cause data inconsistency?
Does it not 'lock' the rows automatically?

Thank you.

jglathe · 2013-10-29

Andwian wrote:

What if we do not use LOCKTABLE?
Is it dangerous?
Can it cause data inconsistency?
Does it not 'lock' the rows automatically?

Thank you.

Hi,
I'd say yes, depends on what you call consistent, and yes. Using locktable defines the explicit starting point of a transaction. The actual locking takes place when you read rows, or when you insert/modify them. The use of a certain sequence of locktable/read access is required to get deterministic posting behaviour, and to avoid deadlocks. As for consistency, this is another matter. In CU 12, the G/L Entry table is deliberately marked as consistent depending on a calculation. This will be checked on commit and an error raised when it's not marked consistent.

with best regards

Jens

Andwian · 2013-11-04

Thanks Jens.

LOCKTABLE

Comments

Categories