Re: Please help: SQL ERROR: -243

June, What an excelent response! After more reading and input from folks like you, I've decided on "SET LOCK MODE TO WAIT 1800". So, if the process times out after 1/2hr, then an error is probably a good thing. - Randy Galbraith Bulk emailers please note: Spam/UCE is not welcome at inbox. June Tong wrote: > Randy Galbraith wrote: > > > I've written a program in ESQL/C (my first) that reads through a table > > and dumps it to an ascii file. Most of the time I works just fine, > > however occasionally I get this error: > > > > SQL ERROR: -243 Could not position within a table (%s). > > > > ISAM ERROR: -144 ISAM error: key value locked > > > > Another process is concurrently accessing the table. From my reading it > > looks like I will have to issue a "SET ISOLATION" and/or "SET LOCK MODE" > > in my program. This raises two issues: (1) I'm not sure which of these > > options are the best for my situation (or how to tell), (2) I have no > > control of the other process that is accessing the database, so I'm > > assuming that will effect which options to set. > > Your program is trying to access a row that someone else has locked. If you > are only trying to read it (SELECT), then you can use Dirty Read isolation > level, and read the uncommitted data. Be aware that this other user is > modifying the data (inserting, updating, or deleting), and has not yet > executed the COMMIT WORK statement; therefore, if you choose to read it > anyway (using Dirty Read) there is a chance that the user will rollback the > transaction and the data you read is not actually valid. (On the upside, > most transactions get committed, rather than rolled back.) If you are > trying to update the row in any way, you cannot use Dirty Read to avoid the > error; Dirty Read only works on reads. > > If you want to make sure that your program does not read any uncommitted > data, then you must use SET LOCK MODE TO WAIT [n]. The main downside to > this how long you're going to wait, since you have no control of the other > process. If you don't specify n, it waits forever, and that can be a really > long time. If you choose a number, say 10, then you have to decide what > you're going to do if that time expires without the other user freeing the > lock. > > I'm afraid you'll have to decide yourself, based on this, which one to > choose. > > June > -- > june_t@hotmail.com > Grounded in Palo Alto, living on M&M's (plain)