Transaction keyword in Nested Transaction

Kalan

Kalan

Member
Hi All,

I knew why the below error is coming, but my requirement is as per my company coding standard I have to explicitly specify the DO TRANSACTION keyword regardless of this below warning message. Could you pls suggest me how to retain this keyword in nested transaction scope and at the same time to avoid the warning message?

Thanks in advance.
Issue:
WARNING--TRANSACTION keyword given within actual transaction level
There is a transaction already active. Either because you have nested transactions using the TRANSACTION keyword or because an implicit transaction is active in the block enclosing the TRANSACTION keyword.

​
 
Such coding standards are subject to discussion - at least. It can be a good or a bad thing to explicitly try to control the transaction scope ...

To find out whether a transaction is already active when your DO TRANSACTION statement fires you have several options:

  • For one you can compile the code with the LISTING option (see the online help on the compile statement) which will produce an output that will show you the scopes of transactions and buffers.
  • You can also use the TRANSACTION function which will return TRUE or FALSE when questioned at runtime.
Unless on purpose for rare business cases you should not have sub-transactions because they might cause unexpected transaction behavior - therefore it is a good thing when the compiler warns you ...


Heavy Regards, RealHeavyDude.
 
Thanks Dude, So wats the solution approach to rectify this warning message? Do I need to remove the keyword transaction after identifying the place thru LISTING output file?
 
Whether you should remove the TRANSACTION keyword depends on your business case but I would speculate that your business case does not require the usage of sub-transactions, instead it would recommend the opposite - therefore I would remove the TRANSACTION keyword to remove the sub-transaction and thereby removing the possible cause for possibly unpredictable application behavior.

Maxim's solution just prevents the warning message raised at compile time - but it won't change anything when the compiled code is executed - therefore you should remove the issue and not the symptom in the first place. But that's just IMHO, of course.

Heavy Regards, RealHeavyDude.
 
The answer, of course, depends on what is right. If it is correct from a business perspective that the transaction is scoped to the outer transaction then your coding standard is wrong and you should remove the transaction keyword from the inner block. A coding standard which says to use a keyword that is a) meaningless in the context and b) produces an error if used is a coding standard which needs reexamination. On the other hand, it may be that the right place for the transaction block is the inner block where you are trying to put the keyword. If that is correct, then the problem is that you have unintentionally created a transaction block at a higher level. If so, you need to figure out what is creating that transaction block. It might, for example, be poorly scoped buffers, e.g., referring to a buffer in your transaction block which is also referred to outside that block. Fix that and the problem will go away. Or, it could be another update to a different table. Then you need to ask yourself what is the business rule? Is it that those two updates are separate transactions? If so, use buffer scoping and the transaction keyword to limit the scope of the update and make them separate. Or, if it is that the business rule is that both are part of the same transaction, then you are back with case 1, i.e., you *want* the larger scoped transaction.
 
Kalan said:
my requirement is as per my company coding standard I have to explicitly specify the DO TRANSACTION keyword regardless of this below warning message. Could you pls suggest me how to retain this keyword in nested transaction scope and at the same time to avoid the warning message?
Click to expand...

Having the TRANSACTION keyword as mandatory for all blocks that update the database is a good standard, now depending on the business rules your transaction block might be bigger or smaller and it might touch one or more tables... there is no need to add TRANSACTION to all other blocks in that transaction unit unless you really have a need for sub-transactions.

When you might need sub-transactions is when you would like to have everything updated in a single transaction but if anything goes wrong at the sub-transaction level you still need to commit the transaction work above it and maybe carry on with something else... things that are optional and if it fails at the time there is an option to make them later on, you don't need to cancel the whole thing because of them.

But when you need something like that the least you can do it to make that a separate block by making it more clear... like making an internal procedure for it, in that sub-block you should again use TRANSACTION since you are updating the database and you can not know if when you do that you are already in a transaction or not, the compiler will get away with it as it should.

Code: 
DO  TRANSACTION:
    FOR EACH customer TRANSACTION:
    END.
END.

vs.

Code: 
DO TRANSACTION:
    RUN subTransactionBlock.
END.

PROCEDURE subTransactionBlock:
    FOR EACH customer TRANSACTION:
    END.
END PROCEDURE.
 
You must log in or register to reply here.
Back
Top