Finance | Project Operations, Human Resources, ...

How to roll back an update?

(0) Share

Report

Posted on by junior AX

1,552

So for each update_recordset i need ttsbegin and ttscommit

and if i try to put 1 ttsbegin and 1 ttscommit and inside them 2 updates.... the update value won't take place unless it reaches ttscommit.

what i want is i want to update a record and do some logic based on the updated value and if an error happens i won't this update to be rolled back, but i won't be able to see updated value and do some logic based on it unless i commit it. So any suggestions?

I have the same question (0)

All responses (16)

Answers (0)

Suggested answer

Martin Dráb 237,967 Most Valuable Professional on at

Like (1)

Report

If "if an error happens" means "after throwing an exception", then the transaction was already aborted.

It sounds that you want to update the record, commit the transaction and only after that running your additional logic.

By the way, update_recordset makes its own transaction. If you have a standalone update_recordset statement and don't need additional changes to be committed (rolled back) together with it, you don't need tttsbegin/ttscommit.

Was this reply helpful? Yes No
Suggested answer

Vishal Dhavgaye 405 on at

Like (0)

Report

Following article explains transaction integrity, although it is for AX2012 but also applied to D365,

docs.microsoft.com/.../transaction-integrity

Was this reply helpful? Yes No
Suggested answer

Rahul Mohta 21,032 on at

Like (0)

Report

could use events to capture the value separately and then use it to compare

Was this reply helpful? Yes No
junior AX 1,552 on at

Like (0)

Report
Hi,

you are right there is no need for ttsbegin and ttscommit if i use update_recordset ( i didn't know about this)

But what i'm doing is, that i'm updating a record and then doing some logic based on that updated value, then after i finish i get the updated value back to what it was. But what if an error happens before i get the value back to what it was. i want the update to be rolled back, so what to do in such case??

try { update_recordset table setting field = false where table.Id == enumerator.current(); // do some logic based on the updated value throw error("error"); //some logic } catch { }

Was this reply helpful? Yes No
Suggested answer

Martin Dráb 237,967 Most Valuable Professional on at

Like (0)

Report
It's not clear to me what you mean by "getting the updated value back to what it was", but if you want to roll back the update when the error is thrown, simply put both things to a singe database transaction:

ttsbegin; update_recordset table setting field = false where table.Id == enumerator.current(); // do some logic based on the updated value throw error("error"); //some logic ttscommit;

When the error is thrown, all changes done in the transaction will be rolled back.

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,162 Moderator on at

Like (0)

Report

All data operations that you made in a transaction are rolled back if you throw an error or call ttsabort.

Was this reply helpful? Yes No
junior AX 1,552 on at

Like (0)

Report
The problem is when i put ttsbegin and ttscommit before the update, i won't be able to get the value of the updated record.

I mean like this, i want to update the record then based on the values of the update i just did, i want to do some logic, Now with ttsbegin and ttscommit, the value of the record is still the old value so in the example below, i won't be able to info the new values that i just updated, as the table is still saving the old value which was true.

However if i remove ttsbegin and ttscommit, when i do the info i will get the new records i just updated but if any error happens before the info, the update won't be rolled back and if i check the table i will see the updated value even though the error happens.

I just put the info for example but i will do logic other than the info

try { ttsbegin; Table table; update_recordset table setting field = false where table.Id == enumerator.current(); throw error("error"); Table table1; while select table1 where table1.field == false { Info(strFmt("%1",table1.field)); } ttscommit; } catch { }

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,162 Moderator on at

Like (0)

Report

In your code you are throwing an error and therefore the execution never goes in the part where you have your while select statement and infolog printing. That's why "you won't be able to get the value of the updated record". When an error is thrown, the transaction is rolled back and the execution jumps to the catch statement.

You can definetely see the value of your updated record inside your transaction. Others can't, until it's committed to the database.

But I consider you to rethink about your solution. Why would you want to update some table just to cancel the update right after that? What is the point? Why can't you just update the second table directly?

What is your business requirement / functional requirement?

Was this reply helpful? Yes No
junior AX 1,552 on at

Like (0)

Report

sorry i mean put the throw error after the info (still the same result)

without ttsbegin and ttscommit you'll get the new updated values when you info

try to put ttsbegin and ttscommit, the info won't get the updated values because it did't reach the ttscommit

As u can see, i'm getting the Ids from an enumerator, i need to change the flag of the coming Ids temporary, and do some logic based on this updated flag value then after it i will change it back to what it was. But if an error happens before getting them back to what they were, then the values will still be updated and not rolled back if i didn't use ttsbegin and ttscommit. And if i used ttsbegin and ttscommit, then i can't do logic based on the updated flag value because it's still seeing the old value.

let's say i want this flag to be changed temporary because a query has a range on a flag = false so i need to prepare the coming values to the query to work.

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,162 Moderator on at

Like (0)

Report

I'm quite sure you could run your "logic based on updated flag" without actually updating the first table.

Here's your flow

1) Start with some information

2) Update table 1 with this information

3) Update table 2, based on information of table 1 (that was updated in step 2)

4) Undo changes in table 1

You could do just

1) Start with some information

2) Update table 2, based on this information

Also, here's an illustration that shows that you can access the updated information inside the transaction. So you have some mistake in your code. You haven't shared your latest code, so we can't spot any issues in it.

Was this reply helpful? Yes No