Release statement

[WSS_R2D2]

Hi all!

I've been working with progress back in the day's and went into web dev for years with asp to come back recently in progress.. Since the developpment is quite not the same as for the database access, i.e asp/sqlServer you need to create a recordset, build you queries, build connections etc etc then be carefull to release all your objects etc.. whereas with progress it's a direct db access.. I am having a hard time to re-adapt my self back to this approach though!

My question is that I've just seen the release statement. ie.
find <table>.
release <table>.

I see that we could use the release statement no regards to the lock specified on the find statement. I would like to know which practice would be the best:
-> doing a find, keep it until we need it and never releasing it ( well until progress release it from the buffer , that is when the page scoope is finsh ) or
-> doing a find, assigning the values you need inside variables and releasing it from the buffer when done assigning your variables.

See, am quite in the same mental way that you would be coding with asp, you make your db connection and as soon as you could free either your recordset or your object than the best it is.

So basically, I suppose that the best practice, no regards that this is a client/server application would be to perfom a find -> assigning variables with the values and releasing the find from the buffer the quicker possible. Am I correct?

Thanks for any input.

Cheers

 

[mpowell_esq]

Locking

It depends upon locking practise. Whilst ever the record is in the buffer that is no problem, the problem occurs how the record is assigned to the buffer. It depends upon the lock used . The record can stay in the buffer for as long as you like, alter the lock which the record has. You can find the record NO-LOCK then execute your block. ONLY upgarde to EXCLUSIVE-LOCK when making changes to the db record. Once you have made the changes, make sure the lock is then downgraded.
Regards

 

[sanderpors]

I would like to add a little here.

If you have an EXCLUSIVE-LOCK on the current record.
With the RELEASE statement the DB-triggers for that record are fired. Alltough afterwards the record is not accesable anymore, the record wil only be released from the lock-table at the end of your transaction scope.

As a means of best practice I would sugest the following:

DEF VAR c_gift AS CHR NO-UNDO.
DEF BUFFER b-cust for customer.

trans:
FOR EACH customer
WHERE customer.gender = "female"


ON ERROR UNDU trans, RETRY trans:

RUN PriGift(input customer.hobbies, output c_gift).


IF c_gift = "":U THEN NEXT trans.

FIND FIRST b-cust EXCLUSIVE-LOCK
WHERE ROW-ID(b-cust) = ROW-ID(customer).

ASSING b-cust.gift = c_gift.

RELEASE b-cust.
/* now b-cust is not accessable anymore for this procedure */

​

END. /* for each female customer */

/* only at the next iteration b-cust is available for exclusive-locking by others */

 

[jongpau]

Or to make it even more transparent what's happening on a transactional level (to anyone looking at the code) what is happening, you can do (note the bold stuff):

DEF VAR c_gift AS CHAR NO-UNDO.  
DEF BUFFER b-cust for customer.    

FOR EACH customer [B]NO-LOCK[/B] 
WHERE customer.gender = "female":   
  RUN PriGift(input customer.hobbies, output c_gift).      
  IF c_gift = "":U THEN NEXT trans.    
  
  [B]trans:
  DO TRANSACTION ON ERROR UNDO trans, RETRY trans:[/B]
    FIND FIRST b-cust EXCLUSIVE-LOCK
    WHERE ROW-ID(b-cust) = ROW-ID(customer).    
    ASSING b-cust.gift = c_gift.
    RELEASE b-cust.  /* now b-cust is not accessable anymore for this procedure */ 
  [B]END. /* transaction */[/B]
END. /* for each female customer */

And in that, you can question whether or not the ON ERROR UNDO, RETRY is very suitable -- might be a nice cause for an endless loop -- but that depends on the actual logic and what needs to be done. Ultimately you can prevent any endless loop problems with an IF RETRY THEN...