Undo Transaction Block in Persistent Procedure

[ChrisJRutter]

Can anyone help me here, I'm new to the whole persistent thing....

I have a persistent procedure that adds or updates a record:

ON CLOSE OF THIS-PROCEDURE
DO:
... check any widgets have been modified
... if any have then ask the user if they want to cancel their changes

RUN disable_UI.
END.

MAIN-BLOCK: DO TRANSACTION ON ERROR UNDO, LEAVE
ON END-KEY UNDO, LEAVE:

.... create or find record EXCLUSIVE-LOCK.
.... various fields enabled for input
.... buttons bu_save and bu_cancel are also present

RUN enable_UI.

IF NOT THIS-PROCEDUREERSISTENT THEN
WAIT-FOR CLOSE OF THIS-PROCEDURE OR CHOOSE OF bu_cancel.
END.

My questions is; how do I go about undoing the transaction block if;
a) the cancel button is selected or;
b) the window is closed (using x) and data entry has taken place.

I have a code block that walks the widget tree of the frame and checks the modified attribute of appropriate widgets. I have this firing on "CLOSE of THIS-PROCEDURE" and "CLOSE of THIS-PROCEDURE" firing from "CHOOSE of bu_cancel" which works fine but how do I then undo the transaction block MAIN-BLOCK if needed.

Thanks in advance.
Chris

 

[jongpau]

I don't think what you are doing is "right" at all.

First of all, a wait-for in a persistent procedure is no good. A persistent procedure is nice to fire and leave in memory, for instance for you to use internal procedures to handle all sorts logic for you. Firing a persistent procedure for a transaction in the way that you did it is well, to be honest, no good at all.

Finding a record with exclusive lock in the main block of a persistent procedure is just not on really...

Further, always be careful with locking records in persistent procedures; these can be very dangerous and cause locking problems (Progress can keep records locked while the procedure is in memory). So, when updating a record in a persistent procedure you should ALWAYS use the RELEASE statement at the end of the transaction for ALL tables/records that you may have updated or used in a FIND with EXCLUSIVE-LOCK

Last of all (but certainly not least); if you are using event driven programming, you want to try and keep your transactions as small and short as possible. If I were you I would change your code so that (all this can be put in an internal procedure so you can also execute this after your widget tree traversing finds out the user changed the record):
- Validate data entered by the user in the form - if correct proceed, otherwise give user appropriate error message(s) and do nothing else
- Find the record exclusive lock
- Start a transaction
- Update the record
- Release the record
- End the transaction
- Close the window or dialog box if required


That was it at the moment -- I may have forgotten a thing or two. Maybe you can tell us a little more about what it is you are trying to do with your procedure?

 

[ChrisJRutter]

Thanks for this, yes I was totally confused over the use of persistent procedures. What you've said makes complete sense. Using a persistent procedure in this instance is crazy.

Cheers
Chris