Re: ODBC, NT and Workgroup problem

Perhaps the type of locking used by the datasource is not the issue? The isolation mode (or concurrency) of the user's process is what you need to consider. The sugestion by Mr. Kagel to "SET LOCK MODE TO WAIT n" is one posible solution. Another would be to "SET ISOLATION TO DIRTY READ". Then the insert statement will be able to validate any unique constraint violations. -- Regards, Walter S. Tyszka (wstyszka@ingr.com) * Standard disclaimers apply * > > > From: Jun Nolasco[SMTP:NOLASCO@INX.NET] > > Sent: Thursday, October 22, 1998 10:14:13 PM > > To: informix-list@iiug.org > > Subject: Re: ODBC, NT and Workgroup problem > > > But, why is it that even with row level locking, these errors still > occur eventhough no one else is currently using the record in question > (but with others holding locks on other records)? And from the error > messages, it looks like it is the index record that is locked, not the > data record. What gives? > > Jun Nolasco > nolasco@inx.net > > > Art S. Kagel wrote: > > > > 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 >