The default isolation level for the MS SQL Server DataServer is read uncommitted. At this level, a SHARE-LOCK and NO-LOCK are identical from the perspective of the DataServer and the MS SQL Server data source. The higher isolation levels will determine what kind of share locks will take effect. In MS SQL Server, a repeatable read and serializable isolation level are synonymous.
The MS SQL Server DataServer ignores ABL SHARE-LOCK option when used in ABL statements. Instead, share locks are governed by the data source and the available ODBC isolation levels. If you wish to change the share lock behavior, you may be able to do so by changing the isolation level at connection time using the -Dsrv parameter.
When you read records with an ABL statement, regardless of whether you include the SHARE-LOCK option, the MS SQL Server data source typically performs as follows:
It puts some form of share lock on the record, page, or table if the ODBC isolation level is anything other than read uncommitted. This occurs regardless of whether the share lock is specified in an ABL statement.
After the data source reads the record, it releases the share lock if the isolation level is read uncommitted or read committed. It may hold share locks until the completion of a transaction if the isolation level is repeatable read or serializable.
If you hold a record with a share lock, other users can usually access that record and apply a share lock, but this is dependent on the isolation level they have selected. Refer to the transaction and locking references in the Microsoft documentation that addresses ODBC programmingor data source reference manuals for more information.
It puts some form of share lock on the record, page, or table if the ODBC isolation level is anything other than read uncommitted. This occurs regardless of whether the share lock is specified in an ABL statement.