Error Codes & Row/Table Locking

Error Codes related to Locking Rows & Tables """""""""""""""""""""""""""""""""""""""""""" For concurrency control, records need to be locked when updating and deleting rows in the same table. I would like to know *exactly which* error codes are returned for 4GL version 4.00 for the situations listed below (if you know the error code, then you can fill in the blank after 'status' for each situation. I found the first one by experimentation). Here's my reason for doing this: Instead of testing 'status' for a negative value and telling the user that "The row couldn't be updated", I would rather tell the user "The row is locked by someone else. Try pressing ESC again." when in fact the row *is* locked by someone else. If some other type of error has occurred, then I would like to display an error message to that effect and take the user out of the UPDATE or DELETE function. Here are some of the error codes I found in the Reference Manual that seem to be relevant; there are probably a few others that I didn't catch: -107 ISAM error: The record is locked. -113 ISAM error: The file is locked. -143 ISAM error: deadlock detected. -233 Cannot read record that is locked by another user. -240 Could not delete a row. -250 Cannot read record from file for update. -263 Could not lock row for UPDATE. -271 Could not insert new row into the table. -291 Table *table-name* is already locked. -346 Could not update a row in the table. -347 Could not open table for exclusive access. -348 Could not read a row from the table. I. When the row is locked by using a cursor declared for Update. ---------------------------------------------------------------- (Updates/deletes are done within transactions.) The row is locked by user A and 1. user B tries to lock the same row (by using the same cursor declared for update), status = -250, "Cannot read record from file for update." (I got this error message right after attempting a fetch with the cursor declared for Update.) 2. user B tries to lock the Table, status = 3. user B tries to INSERT a new row, status = The row is locked by user A in one module. In another module, user B using a different cursor declared for update, 1. tries to lock the row already locked by user A, status = 2. tries to INSERT a new row, status = The row is locked by user A and user B is using a program (without any cursors declared for update) that 1. tries to run the UPDATE command for the locked row, status = 2. tries to run the DELETE command for the locked row, status = 3. tries to INSERT a new row, status = 4. tries to lock the Table, status = The Table is locked (in share mode) by user A and 1. user B tries to lock a row in the Table (using a cursor declared for update), status = The Table is locked (in exclusive mode) by user A and 1. user B tries to lock a row in the Table (using a cursor declared for update), status = II. When the row is NOT locked (no cursors are declared for Update). -------------------------------------------------------------------- User A is doing an UPDATE on the row and 1. user B attempts an Update on the same row, status = 2. user B attempts a Delete on the same row, status = 3. user B attempts an Insert, status = 4. user B attempts to lock the Table, status = User A is doing a DELETE and 1. user B attempts an Update on the same row, status = 2. user B attempts to Delete the same row, status = 3. user B attempts an Insert, status = 4. user B attempts to lock the Table, status = User A is doing an INSERT and 1. user B attempts to Update a row, status = 2. user B attempts to Delete a row, status = 3. user B attempts to Insert a row, status = 4. user B attempts to lock the Table, status = ============================================================ ============================================================ If you know the value of status, please fill in and post to the List. Thanks, John Baker U.S. Army Information Systems Command - Lex Lexington - Blue Grass Army Depot Lexington, KY 40511-5109 E-mail: jbaker@lexington-emh2.army.mil Phone: (606) 293-3644 or -3743