find current with do transaction

shivaprasath143

New Member
Hello ,

Can someone explain the diff between these 2 queries. Also pls suggest is it good to use find current xXx in no-lock after the transaction or release the table xXx using Release statement.

1.

do transaction:
find current xXx exclusive-lock no-error.
xXx.yYy = zZz.
find current xXx no-lock no-error.
end.

2.

do transaction:
find current xXx exclusive-lock no-error.
xXx.yYy = zZz.
end.
find current xXx no-lock no-error.
 

TomBascom

Curmudgeon
RELEASE does not do what you think it does. It has absolutely nothing to do with changing lock status.

"grep -i release *.[ipw]" is an excellent way to find code that is probably filled with all sorts of bugs.

Both of your examples above are examples of code which has not properly scoped records and transactions. The programmer is attempting to work around that with FIND CURRENT. Both examples are red flags from a bug hunting perspective.

The correct way to update data is to use a strong-scoped buffer in a transaction block. Like this:
Code:
define buffer updCustomer for customer.

/* stuff happens... */

do for updCustomer transaction:
  find updCustomer exclusive-lock where updCustomer.custNum  = customer.custNum no-error.
  if available(  updCustomer ) then
    do:
      updCustomer.discount = 99.
    end.
   else
    do:
      /* handle the not available condition if you'd like to but do NOT interact with the user to do so! */
    end.
end. /* do for updCustomer */

The important parts of this are:
1) There is NO user-interaction - a user cannot go to lunch and hold a lock for an hour. Or an open transaction and make the bi grow hugely.
2) The lock will not escape the "do for" block and be automatically downgraded to a share-lock.
3) If the compiler complains that there is already a transaction active or that you have already referenced updCustomer then you have made a mistake and need to fix it rather than ignore it.
4) There is no need to try to use RELEASE or FIND CURRENT to (try to) work around bad coding
 

shivaprasath143

New Member
Thanks Tom!. This is really helpful information.

One more question. Can I define a single buffer a table and use it across a single procedure.

For example: I have a table called customer. I defined bbcustomer buffer for it. Is it okay to use the same buffer in the entire program or its better to define multiple buffers for same table for different update scenario.
 

Cringer

ProgressTalk.com Moderator
Staff member
You can use the same buffer for multiple updates. As the transaction is scoped strongly to the buffer, the record in the buffer goes out of scope at the end of the transaction.
 
Top