This topic explains how locking is used in the two database options for Microsoft Dynamics NAV:
-
Classic Database Server
-
The SQL Server Option
 Important |
|---|
|
The information in the following sections only covers the default transaction type UpdateNoLocks for the SQL Server Option for Microsoft Dynamics NAV. For information about the other transaction types, see C/SIDE Reference Guide. |
Both Server Options
Locking
In the beginning of a transaction, the data that you read is not locked. This means that reading data does not conflict with transactions that modify the same data. If you want to ensure that you are reading the latest data from a table, you must lock the table before you read it.
Locking Single Records
Usually, you must not lock a record before you read it even though you may want to modify or delete it afterward. When you try to modify or delete the record, you get an error message if another transaction has modified or deleted the record. You receive this error message because C/SIDE checks the timestamp that it keeps on all the records in a database and detects that the timestamp on the copy you have read is different from the timestamp on the modified record in the database.
Locking Record Sets
Usually, you lock a table before reading a set of records in that table if you want to read these records again to modify or delete them. You must lock the table to ensure that another transaction does not modify these records.
You will not receive an error message if you do not lock the table even though the records have been modified as a result of other transactions being carried out while you were reading them.
Minimizing Deadlocks
To minimize the amount of deadlocks that occur, you must lock records and tables in the same order for all transactions. You can also try to locate areas where you lock more records and tables than you actually need, and then diminish the extent of these locks or remove them completely. This can prevent conflicts from occurring that involve these records and tables.
If this does not prevent deadlocks, you can, lock more records and tables to prevent transactions from running concurrently.
If you cannot prevent the occurrence of deadlocks by programming, you must run the deadlocking transactions separately.