Re: SOS: locked rows are blocking table read !?

Axel Sander wrote: > > Hi, > > I just encountered a nasty problem. Our application is using SE 5.0 under > Solaris and is working fine (but we're planning an upgrade to IDS 7.x later > this year). First we are porting our program modules to Windows NT SP4 with > IDS 7.30-TC9. There were no problems on compilation but now I got the > following runtime problem: > This is an OLTP application, so users start working interactively. This can > lead to temporary open transactions, that are not commited, if they have to > look something up, go to luch and so on. Newly created or updated records > are meanwhile locked by this user - *this* is OK for me;-) No, the developers should be flogged . . . . <G> > But this records can't be *read* by any other process. Instead the access seems to be > blocked - if I do a simple "select" statement from dbaccess to show all > records in a table I get: > "-244: Could not do a physical-order read to fetch next row (ISAM-error > -107: record is locked)"> most times followed by a > "-245: could not position within a file via an index" > What's the isolation level on the application? Dirty reads should allow for SELECT while an UPDATE is taking place. > All tables are created with row level locking, so the locking of a single > record shouldn't block the complete table, a *read* should *always* be > allowed. The SE doesn't works this way, so I wonder, if I'm missing > something in the online configuration or running into an informix bug. > > Any hints for me? > Application design? . . . <G> John Carlson Informix DBA WHSmith USA My thoughts, musings, and scribbles are my own and not that of WHSmith USA.

On Tue, 19 Oct 1999 15:01:58 -0400, "Carlson@WHSmith" <carlson1@bellsouth.net> wrote: >> are meanwhile locked by this user - *this* is OK for me;-) > >No, the developers should be flogged . . . . <G> That's a burden of my predecessors - they left me with this and are far, far away - and I think, now I know why... >What's the isolation level on the application? Dirty reads should allow >for SELECT while an UPDATE is taking place. THX *that's* the hint I needed Axel