transaction levels

Adri

Dear reader,

We have to following problem:
when we do a stock conversion this does the following:
first negative adjustment (commit)
then check if there is no other costs booked on the stock (commit)

make positive adjustment with the total costs (commit)

These are three different processes.

Sometimes, when the positive adjustment is done there is a 'locked by another user' and this part is undone. The situation then is, that the negative adjustment is done, the check as well, but the positive is not. In short: The piece has disappeared.

Is it possible to make one transaction which undoes everything when an error occurs in the second or third part?

Kind regards,
Adri

logger

Hi @Adri ,
As I got your question, you have 2 options here:
1. Get rid of intermediate commits and make the big one in the end;
2. Manually (in the code) roll back previous commited transactions (creating corrective entries) in the case of error.

Hope my suggestions are useful for you. If not, we can discuss your issue to find more appropeiate way.

latronamarran

each commit prevents the roll back of its process. so unfortunately it doesn't work like the way you hope.

logger

Hi @Adri ,
As I got your question, you have 2 options here:
1. Get rid of intermediate commits and make the big one in the end;
2. Manually (in the code) roll back previous commited transactions (creating corrective entries) in the case of error.

Hope my suggestions are useful for you. If not, we can discuss your issue to find more appropeiate way.

latronamarran

but why 3 different processes? they seem strictly related with each other. using commit with this kind of procedure is higly problematic.

Slawek_Guzek

It might be a leftover from old days when a single write locked the whole table. COMMITs were used to improve write concurrency

Adri

The 3 existing processes are standard processes which are reused. Unfortunately we cannot alter these (not allowed to compile, license issue)

I hope it was possible to have to following construction:

DO TRANSACTION
process 1 (which processes and commits)
process 2 (which processes and commits)
process 3 (which processes and commits)
END TRANSACTION

And when something goes wrong in one of the three commits it would roll back all.

latronamarran

each commit prevents the roll back of its process. so unfortunately it doesn't work like the way you hope.

logger

@Adri , COMMIT is called so because it commits transaction. Please, refer the NAV help.
Only one thing I can advice you is to copy standard functionality to new objects in available range fpr development, and replace calls in the system. But be aware that it's bad practise.

Adri

Thank you all for your help! I am quite new in C/AL, but programmed in other languages.

@Logger: There are programming languages who only commit when the transaction is finished. You can assign/commit anything at any time, but it is writen to the database then the transaction has finished. With for example "progress" (also a 4GL language) you can do as described above.
In "Progress" the commit 'writes' the database changes, but when something is wrong everything is rolled back. I hoped in C/AL this was possible as well.

logger

@Adri , thanks for the info, will take it into account!

Slawek_Guzek

Adri wrote: »

There are programming languages who only commit when the transaction is finished.

C/AL works exactly that way. The first database write opens transaction, which is kept open until the code finishes and control is returned to a user. COMMIT is just a way to flush it quicker, on request.