Re: ODBC, NT and Workgroup problem

Jun Nolasco wrote: [Reply SNIPPED] > asevillano@gesfor.es wrote: > > > > Hello all, > > I have a problem in a NT 4.0 with INFORMIX Workgroup 7.23 and ODBC (Informix- > > cli). When I insert a lot of records with a unique program there is no > > problem, but when I execute several program at the same time begin to appear > > those errors: > > -244: [INTERSOLV][ODBC Informix driver][Informix]Could not do a physical-order> > read to fetch nect row. (S1000) > > -243: [INTERSOLV][ODBC Informix driver][Informix]Could not position within a > > table (%s). (S1000) and > > -271: [INTERSOLV][ODBC Informix driver][Informix]Could not insert new row into > > the table. (S1000)> > > > Is it INFORMIX threadsafe? Yes it is, but that is not your problem. You have concurrency issues. You either need to tell the database to wait for locks to clear instead of returning lock errors or code your program to spin or sleep for a bit and then retry the operation. You can set the locking wait mode with: SET LOCK MODE TO WAIT; which will wait forever for the lock to clear or: SET LOCK MODE TO WAIT n; where n is a number of seconds to wait. In that latter case if the lock has not been released before the time expires you will still get the errors 243, 244, 271 and others and so should code to handle them reasonably. You can scan the Informix Error Codes manual to determine the few other codes that indicate a lockout condition. Normally locks are very short lived in a system with properly written clients and so the "WAIT n" version with 'n' = 5 is usually more than sufficient to solve concurrency problems without hanging the client if someone locks a row and goes on vacation to Accapulco for a week. Jun's suggestion to change to row level locking will of course reduce the number of concurrency caused lockouts and so I support that suggestion as well. It just does not go far enough. Art S. Kagel