This is one of two locking methods available with Acu4GL for MSSQL. The methods are accessed via two configuration variables (A-MSSQL-VISION-LOCKS-FILE and A-MSSQL-NATIVE-LOCK-TIMEOUT). The lock method used is determined as follows: If A-MSSQL-VISION-LOCKS-FILE is set to the name of a Vision file that can be opened I/O, and has the correct structure, then the Vision file is used to hold lock information. Otherwise, if A-MSSQL-NATIVE-LOCK-TIMEOUT is set to a positive value, then native locking is used. Otherwise, the AcuLocks table is used to hold locks.
This locking method enables you to use Microsoft SQL Server native locks if you explicitly code transactions in your COBOL program. You can access this method by setting the configuration variable A-MSSQL-NATIVE-LOCK-TIMEOUT to a positive value. This value will be the number of seconds that a connection will wait for a timeout to occur. When such a timeout occurs (for any reason), the Acu4GL product assumes that the timeout was due to a locked record, and will return error 99 (record locked). If you set this variable but do not explicitly code transactions in your COBOL program, record locking will not occur. Note that the Acu4GL product will wait the number of seconds specified, and your application may seem to hang if the timeout is too long. On the other hand, if the timeout is too short, you may get record locked errors when the network is slow.
Microsoft SQL Server uses a page locking mechanism, and so this method of locking records may cause your application to return spurious record locked errors due to a record being locked on the same page as the record you are trying to access. SQL Server 7.0 uses row-level locking, but because of the timing issue, use of this option is discouraged.
A-MSSQL-VISION-LOCKS-FILE runtime configuration variable and section B.5.1 "Table Locking" of this appendix.