RecordLevel Locking

Hi all, I have a question about RecordLevel locking (2.50 and greater). It seems to be that only in posting functions recordlevelocking is being used in the code by Navision. Why is it not being used in other objects? Or do I miss something? Thanks, Roelof.

The command RECORDLEVELLOCKING is used to determin wich database you are the installation on, so the RECORDLEVELLOCKING command is not the command that actualle puts the locks on the table. So if you look further down in the code you will see that the RECORDLEVELLOCKING allways is followed by an TABLELOCK command wich is the command that actually puts the locks on the tables. And the reason you need to know wich database you are running on when you set a TABLELOCK command is that the TABLELOCK command is used differently on C/SIDE and SQL server. SQL server is using a totally different locking scheme then what is used in C/SIDE. RECORDLEVELLOCKING is returning a TRUE or FALSE value depening on your database option. The reason you find this only in the posting routines is that this is the only place (i think) where you have the need to put an explicit lock on your table in C/SIDE to make sure that no one is inserting records in the ledger tables when you are posting. Elswhere a tablelock is automatically put on a C/SIDE table when ever it is inserted to or modified in any way. The locking scheme in SQL server is much more complex and really needs to be learned to be fully understood. Using LOCKTABLE with SQL Server You can only use the default values for the available parameters. 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.

Just to add… On the SQL version, LOCKTABLE does not place any locks at all on the table. Only the operations that follow it will place the appropriate locks. The READ UNCOMMITTED hints will be removed from queries on the ‘locked’ table, so that the SERIALIZABLE isolation level (already set) will instead be active. The UPDLOCK hint is added to all queries on the ‘locked’ table.

But why is it only being used in posting functions and not in other objects.

Well, it can be used anywhere that there are benefits from knowing the locking granularity of the database and acting accoringly. It was done only in this area probably because it was the most critical and there was not time to evaluate the entire standard application code in order to do similar checks, when 2.5 was due for release.