Bad Queries

Interesting.... glad to see they backed that out. Now if we could just get the easy feature of telling who has a record locked in the 4GL.....
 
Oh okay. I jumped from 11.3 to 11.5 so only noticed it in 11.5.

Never used this in deployed code, only tools.

TheMadDBA - _Connect.Connect-PID ?

Im just digging myself deeper now.
 
Yeah definitely needs to be a nice way through ABL to identify who has a record locked. Possibly a "lock" object.

That'd be great.

11.5.1 is in the queue to fix some web speed issues. Just had so many upgrades recently i want some stability. User base flipped out when all the selection rows on browsers went translucent and grey!!
 
TheMadDBA said:
I meant from a 4GL perspective where the code is trying to lock a record with NO-WAIT and should be able to tell how has it locked without digging through _Lock (which can be very very bad sometimes).

Enhancement request added (again)...

https://community.progress.com/comm...play_which_userconnection_has_a_record_locked
Click to expand...
The infuriating thing is that you often get the information if you try and lock a record without trapping the fact it's already locked, but then the problem is handled poorly. But there's no way to get the information yourself easily when you handle the problem. Grrr.
 
The motivation for the 11.4 change was to make _Lock less expensive to read. It would be interesting to see real-world results for the difference between the 11.5.1 implementation and the prior one (10.x/early 11.x) for reading lots of lock table entries (what we previously would have described as bad code).
 
Pretty off topic but did anyone else who used the _Lock table have to rewrite bits of code for 11.5? They changed how the _lock table was sequenced and it screwed all my optimisation/Debug tools.
Click to expand...

Whatever you think was optimizing _Lock previous to 11.4 wasn't.

You were just fooling yourself.
 
You must log in or register to reply here.
Back
Top