Tweet
** This thread discusses the article: TechTip: Record Locks **
** This thread discusses the Content article: TechTip: Record Locks0
** This thread discusses the Content article: TechTip: Record Locks0
-
-
TechTip: Record Locks
** This thread discusses the article: TechTip: Record Locks **
An alert reader tried this solution, and it just kept trying to read the same record over and over. The sample code I posted wouldn't normally(*) even be getting record locks, since the file isn't opened for update. Since the common technique for dealing with record locks is to retry the read, going to *GETIN after a record lock is bound to work the same way, retrying the failed read. To skip to the next record, it is necessary to read the record with (N) no-lock. Here are a couple of ways to do this. 1. Change to use a full-procedural file, and if there is a record lock error, read the record with READ(N) to skip it. 2. Keep the file as primary, but override it SHARE(*YES), and when a record lock error occurs, call another program that has the file defined the same way; the other program just does a READ(N). (*) It _is_ possible to get record locks on an input file, under commitment control.
Comment