| Lock Statement |
Syntax
Lock [#]filenumber[, recordrange]
filenumber
Use: Required
Data Type: Integer
Any valid file number.
recordrange
Use: Optional
Data Type: Long
A range of records.
The syntax for the recordrange argument is:
recnumber | [start] To end
recnumber
Use: Required
Data Type: Long
The record or byte number at which to commence the lock.
start
Use: Optional
Data Type: Long
The first record or byte number to lock.
end
Use: Required
Data Type: Long
The last record or byte number to lock.
Description
Use the Lock statement in situations where multiple programs or more than one instance of your program may need read and write access to the same data file. The Lock statement prevents another process from accessing a record, a section, or the whole file until it's unlocked by the Unlock statement.
Rules at a Glance
recnumber is interpreted as a record number in the case of random files and a byte number in the case of binary files. Records and bytes in a file are always numbered sequentially from 1 onward.
To lock a particular record, specify its record number, and only that record is locked.
Use the Lock statement, omitting recnumber, to lock the whole file.
The Lock statement locks an entire file opened in input or output (sequential) mode, regardless of the recordrangeargument.
If you omit the start argument in the recnumber syntax, Lock locks all records from the start of the file to record or byte number end.
Attempting to access a locked file or portion of a file returns runtime error 70, "Permission denied."
Programming Tips and Gotchas
You must take care to remove all file locks with the Unlock statement before either closing a file or ending the application; otherwise, you can leave the file in an unstable state. This of course means that, where appropriate, your error-handling routines must be made aware of any locks currently in place so that they may be removed if necessary.
You use the Lock and Unlock statements in pairs, and the argument lists of both statements must match exactly.
The Lock statement doesn't guarantee under all circumstances that the locked file will be protected from access by other processes. There are two circumstances under which an apparent access violation can occur:
The file has already been opened but has not been locked by a process when the current process locks it. However, the first process can't perform operations on the file once the second file successfully locks it.
The block of code responsible for opening the file and then locking it is interrupted by the scheduling policy of the operating system before the file can be locked. If a second process then opens and locks the file, it, not the first process, has sole use of the file.
Because of this, the Lock statement should immediately follow the Open statement in code. This reduces, but doesn't eliminate, the problems that result from the fact that opening and locking a file isn't an atomic operation.