Re: SCO locking problem

In article <37567D99.195193A9@checkstop.com>, Leroy Janda <ljanda@checkstop.com> wrote: > David Mendes wrote: > > > Hi all, > > > > I had a system running SCO 3.4.2 with I-SE v.4.1. The system was running > > for years with some 4GL programs. The system has a load of 2 or 3 users > > on the program. > > We've updated the SE for 7.1. > > Now, when there is only one user everything works fine but when there > > are 2 or more it sometimes hans with the following error: > > > > SQL statement error number -263. > > Could not lock row for UPDATE. > > System error number -107. > > ISAM error: record is locked.> > This is a programming issue. Only one user can update a record at a time. > More than likely is that after the update, the record(s) were not released > or unlocked. The old version just let you get away with this. > > > > > > > It appears to be some kind of misconfiguration in the kernel (?), we > > have the row locking variable in the kernel set to a high value > > (FLCKREC=800) but it still has the problem ? > > > > What is happening ? > > Please help me ! > > > > David Mendes > > HI ALL I can confirm the primary key solution; I moved from 4.10 to 7.20 and suffered from the same problem. When I used set explain on my applications. I found the system was doing a sequential search down some of my bigger tables. I but a primary key on said tables, and re-compiled my application program, the re-compilation is a must, the system will then 'see' the primary keys. Also look at your table design/keys you may need to create more complex keys ie create index agt_01 on agt (ag_cust,ag_number). I hope this helps, it gave me a lot of sleepless nights...!! Dave Br Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.