Re: ISAM Error SQL error -243

I am sure that the program is not multi-threaded. And yes the program is failing on the same table with the locking error. No other program is running simultaneously. The program itself is a sequencial sql statements embedded in a c-program. ARE there any chances that a SQL statement in the next step will start executing before the earlier statement actually completes? The program always fails on the DELETE statement. How Do i monitor the locking using onstat..does it hurt anything to run this commnad on the syatem leve as a programmer.? The table does have indexes on it too..for more information. But yes the program runs successfully sometimes..but the failure frequency is more...and its starts failing after an informix upgrade..does it have anything to do with the high level infomrmix sessions? If I run the program again after the failure..it runs successfully..what does it mean? Please let me know. Jonathan Leffler wrote: > devtakh wrote: > > I am hoping you cold help me. I have a program written in C with > > embedded SQL (CESL) code. In running the program, in one of the delete > > steps, I get an error > > SQL ERROR -243 > > SQL Message = [owner.tabname] > > ISAM error=[-113] > > ISAM error: the file is locked.> > I know that there are no other processes running simultaneously to have > > caused a lock on this table. What might have caused this issue?. The > > problem is if I run the program again, it rUNs fine.. > > Could be many, many different things. > > Is your program multi-threaded? Does it use multiple connections? Are > you sure there are no other processes running? Not even via cron? > > When you run the program the first time, does it sometimes fail or > always fail? Is it always on the same table? When you run the program > the second time, does it always work or only sometimes work? What does > it do that is different on the retry? What happens if you run it a > third time - do you get the first time error again, or the second time > success? > > Have you tried tracking the locks at the time of the failure - via > onstat -k and related analysis? You should not be locked by your own> session, which is why the multiple connections and multi-threaded > questions appear; separate connections in a single program interfere > with each other. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/