Hello Progress Family,
I am trying to learn some of the foundational things that my employer wants me to learn. One of which is Transaction Scope. I was asked if I knew how to tell if there was a transaction currently running (exact wording may be off)? I said other than looking at the code? I was told to look up Is Trans or IsTrans or Is_Trans?????
I am just listing the way I searched for it. I have not found anything yet. Can you all lead me in the correct direction. Either if you could define it or tell me the correct way to write it that would be awesomeness!!!
Thanks,
Tracy
Check the Online Documentation for the "TRANSACTION" function.
As Fencher said, TRANSACTION function tells you whether a transaction is currently active.
As a side note, if you are debugging the code in Debugger, there is a menu item for this: "Debug -> Show Transaction"
Thanks to both of you!!! I appreciate the guidance!!
Tracy
You can also look at the COMPILE statement with the LISTING qualifier.
Hey Dileep,
I ended up finding what he was talking about. I hope they won't mind me posting this. It is from John Campbell's book: Making Good Progress. It may even be something from Progress documentation. Basically the transaction function replaces doing this.
Is Tran is this:
/* is-trans.p */
DEFINE VARIABLE trans-active AS LOG INIT YES.
DO ON ERROR UNDO, RETRY:
trans-active = NO.
UNDO, RETRY.
END.
IF trans-active THEN MESSAGE "Transaction Active" "{1}".
ELSE MESSAGE "Transaction NOT Active" "{1}".
Basically the transaction function written out.
Thanks for all your help.
:-)
Beat me to it Rob! Yes, the compile listing will show you all of the transaction scopes in one compile unit without having to put in tests and messages. It also shows record scope, which is another basic scoping skill you need to master.
Of course, some application knowledge is still required. The compiler is analyzing the procedure as a stand-alone unit, without the context of how you entered it. So if you start a transaction in a.p and then run b.p, everything in b.p is in a transaction regardless of what its compile listing says.
Well, yes, and likewise, if c.p runs b.p *not* in a transaction, then what happens in b.p won't be in a transaction other than as shown in the listing. And, the listing of a.p will show the transaction.
Note to the OP, when you compile a compile unit and use the transaction keyword within an existing transaction, e.g., one that was automatically started because you are updating the database, they compiler will clue you in with a TRANSACTION KEYWORD WITHIN TRANSACTION warning. Unfortunately, this doesn't apply to transactions which propagate from the calling compile unit, like the example Rob gave.