Shared Row Lock

rbuser

I just had our entire production system come to a halt...

The production software uses Sybase 11 and an application built in
Powerbuilder.

I ran a non-trivial (DADE, four dataviews, one master DV with 3 tables
and one detail DV with three tables, two "lookup" DVs of two tables each
- with modified "selectCriteria" to add "OR" functionality to the SQL
object in the detail dv).

Running RB 6.03 under D5, the data properties connected to a TDatabase
with transisolation=DirtyRead and ReadOnly=true and exclusive=false and
keepconnection=true.

The SQL error log indicated that the "other" (powerbuilder) process was
waiting for an 'exclusive intent' lock on a table but my RB process
already held a 'shared intent' lock.
As well, my RB process was waiting for a 'shared row' lock, but the PB
process held an 'exclusive row' lock...

My question: is 'shared row' the proper lock I would expect to see from
'dirtyread'? I'm trying to determine if there is anything I can do to
minimize the impact I have on this DB.

Thanks,
EdB

digitalmetaphors

Frankly I have no idea. 'Shared row' sounds right - the intent of the TQuery
is to read the data, and it certainly doesn't want records deleted or
changed out from underneath it (though you would think that "DirtyRead"
would allow even that.) I would post something in the Borland BDE
newsgroup - I'm sure someone has run up against this before.

--
Cheers,

Tom Ollar
Digital Metaphors Corporation