Recent content by FunkyColdRibena

10.2b, I have examined our test database and shut everything off one bit at a time, until the culprit was revealed the details of which I have now forwarded to the software developers so hopefully the query will now be re written ! Thanks for your suggestions

Hi everyone , thanks for your responses . Would there be anyway of tracking down what query was causing this. I have tried turning off all the app servers and batch processes / remote users but its still the same at 38K/ sec?

yep sorry typo

Hi Tom, I wasn't blaming older versions of Progress, just trying to rationalise where all these locks could be coming from. I agree its totally code related but our application developer is unmoved. I don't develop databases just general IT guy trying to fix customer locking issues.

I did feel they were a tad high! with regards to the no_lock, share lock , I thought that if you didn't put the lock status on each query it defaults to share_lock , and that if you compile ( which I don't have the ability to do , as this is a another companies property ) with the -n parameter...

Hey thanks for replying, I suspect its because it was coded for an older version of Progress where the default was "no_lock" if no locking parameters were specified. Do you think this a reasonable assumption?? . I have added a screen shot from promon R&D , please note the db has been up for only...

So this on a database with virtually nothing active. The application developers tell me this is acceptable , but surely 37k locks (even if they are share locks ) is just wrong!