2005 Nov 08 8:03 AM
Hi,
I have a theoretical question. For example i have to call few transactions in one batch-input program, one by one, till last. If first goes wrong or any other, how can I rollback all changes that have been made in this transaction. Is it COMMIT WORK implicitly called after call transaction and is there a way to avoid that?
Example:
....
fill data for 1. transaction
call transaction '1' ...
fill data for 2. transaction
call transaction '2' ...
....
2005 Nov 08 8:07 AM
No there's no way back - roll back isn't possible !
but you can analyse messagetab (from call ...MESSAGES INTO itab).
and avoid your next step (transaction)
regards Andreas
2005 Nov 08 8:07 AM
No there's no way back - roll back isn't possible !
but you can analyse messagetab (from call ...MESSAGES INTO itab).
and avoid your next step (transaction)
regards Andreas
2005 Nov 08 9:24 AM
Andreas, your solution do not solve the problem. If there's an error in transaction 4, transaction 1 till 3 need to be reversed/cancelled.
I don't think it's possible anyway. If anyone has a nice solution for it, i'm very curious to it.
regards
Hans
2005 Nov 08 9:35 AM
Hallo Hans,
you cannot program in that way:
example transactions:
1) XD02 with kunnr 4711
2) FD32 with kunnr 4711
Why ? - it can be, that customer 4711 is still locked
from TA XD02 - so you get an error if you call FD32.
solution :
1st make all changes with xd02 in your loop and analyze errors from message tab
2nd make credit limit change (fd32) in another loop with the cusomers, which are processed positive with xd02
regards Andreas
2005 Nov 08 2:58 PM
Actually, this isn't theoretical. As Andreas said, trying to back out changes to customers may not be easy to do, but you can certainly back out some transactions.
I have a funds management program that elimintates budgets in Funds Centers and Funds by creating new budget transactions that either set the budget to zero or transfer the budget somewhere else. This can be done for hundreds of Funds Center/Fund combinations. The program analyzes the messages fromn each call transaction and if any transaction fails, then it has to create new transactions to recreate the budgets that were just removed.
It's an extremely complicated program, but it works.
Rob