G
gus bjorklund
Guest
Patrick, This is on purpose. When you already have a lock and then you request another, the higher strength lock is retained if the new lock request is of lower strength than the existing. If the new lock request is higher strength than existing, then the higher strength lock is requested. Also, the 4GL runtime manages buffers in such a way that if two buffers in the same session, but with different names or the same name in nonintersecting scopes, refer to the same record, they are combined so you only get one copy of the record. This is necessary because the database has only one copy of the record. -gus > On May 2, 2018, at 9:11 AM, Patrick Tingen wrote: > > Update from Progress Community > > Patrick Tingen > > We just came across an odd situation. In one of our programs we FIND a record EXCLUSIVE and then run another program. In that program we FIND the record again, but now NO-LOCK and then update it. > > Yeah, I know. It's a bug in our code. > > But whaddayaguess? It just works. The record gets updated without any problem. Is this a bug or just Progress protecting me against myself? Below a test script against the sports db (or here on the ABL dojo). > > DEFINE BUFFER bCust FOR customer. > > FIND bCust NO-LOCK WHERE bCust.custNum = 1. > MESSAGE bCust.name VIEW-AS ALERT-BOX. > > DO TRANSACTION: > FIND bCust EXCLUSIVE-LOCK WHERE bCust.custNum = 1. > RUN updateRecord. > END. > > FIND bCust NO-LOCK WHERE bCust.custNum = 1. > MESSAGE bCust.name VIEW-AS ALERT-BOX. > > PROCEDURE updateRecord: > DEFINE BUFFER bCust FOR customer. > FIND bCust NO-LOCK WHERE bCust.custNum = 1. > ASSIGN bCust.name = 'Hello world ' + STRING(TIME). > END. > > > > View online > > > You received this notification because you subscribed to the forum. To stop receiving updates from only this thread, go here. > > Flag this post as spam/abuse. >
Continue reading...
Continue reading...