if you open the C/AL Symbol Menu and you go to RecVariable (leftsite) -> Miscellaneous -> Locktable
and press there F1 the help window will be opened.
Here per Copy&Paste from the help.
LOCKTABLE (Record)
Use this function to lock a C/SIDE table to protect it from write transactions that conflict with each other.
Record.LOCKTABLE([Wait] [, VersionCheck])
Record
Data type: record
The record from the table that you want to lock.
Wait
Data type: boolean
This parameter tells the system what to do if the table already is locked:
To make...
Enter...
The system wait until the table is unlocked, if another application already has locked the table
TRUE (or leave blank)
LOCKTABLE end with a run-time error, if another application already has locked the table
FALSE
VersionCheck
Data type: boolean
Use this optional parameter to do a version check.
To...
Enter...
Not check the version
FALSE (or leave blank)
Check the version
TRUE
The examples below show you how to use the VersionCheck parameter.
Comments
Because all write operations automatically lock the table in use, LOCKTABLE would appear unnecessary. Imagine, however, a transaction in which an application wants to inspect data and then only possibly change it, with a guarantee that the data being changed has not been modified by other applications since the read. The solution is to explicitly lock the table before the read operation. This makes sure no other application makes changes between the read and the possible write.
Example
The following examples show how to use the LOCKTABLE function.
Without the VersionCheck parameter:
This example uses pseudo-language to show the scope of write locks. Both an explicit lock and an automatic lock are illustrated.
The first line (1) explicitly locks table A. If this explicit lock was not set on table A, the DBMS would automatically lock this table when a record was inserted (3). Table B is not locked explicitly, but is locked automatically by the DBMS when a record is inserted (4). Both locks are active until the system exits the C/AL code module (5).
If a data update depends on a prior read and there is a relatively long time between the read and the write, you may not want to lock the table as you normally would during a transaction. In this way you would avoid preventing other users from updating the table until your transaction is committed. You can do this by using the VersionCheck parameter, which tells the system to compare time stamps to check if a record has been changed.
Consider this example:
Customer.GET('AAA 1050');
{Reading at 10:00.Time stamp}
.
{automatically set to 10:00}
.
.
Customer.LOCKTABLE(TRUE, TRUE);
{Start write transaction at {10:15}
.
.
.
.
{A run-time error occurs if}
Customer.MODIFY
{the time stamp on Customer}
.
{in the data version used in}
.
{the transaction differs}
.
{From the time stamp made}
.
{the last time you read the}
.
{record before the write}
.
{transaction started}
.
{End write transaction}
When the VersionCheck parameter is TRUE, the MODIFY function compares the time stamp of the record you modify within a transaction with the time stamp made the last time you read the record before the transaction started. If these time stamps differ, the record was changed after you read it and before you locked the table. If this occurs, the system displays an error message.
Using LOCKTABLE with SQL Server
The SQL Server Option for Navision only supports the default values for the parameters of the LOCKTABLE function – LOCKTABLE(TRUE,FALSE).
From the point where it takes effect, the LOCKTABLE function causes all operations on the table to be SERIALIZABLE.
If [Wait] is set to FALSE, it will be ignored. You must set [VersionCheck] to FALSE otherwise an error will occur.
Comments
and press there F1 the help window will be opened.
Here per Copy&Paste from the help.
Regards