Is the update method the right one to use?

(0) Share

Report

Posted on by Community Member

I ran an X++ job to update the EFT field (ADCEFTNumber) on every customer record with the PartyNumber from the DirPartyTable but an unwanted side-effect was the Business unit financial dimension being wiped out. I had to get our external AX support team to replace the business unit. They mentioned that the ".update" method that I used could have been the cause.

I've used this before many times for similar record updates without issue. What could have caused this and what should I use instead of ".update"?

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

André Arnaud de Cal... 301,020 Super User 2025 Season 2 on at

Like (0)

Report

Hi AXatak,

You have to provide the detailed script you used to be able to see what could be wrong.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I posted this once already and refreshed to check it persisted. Now 10 minutes later it seems to have disappeared so here goes again:

static void NC_customer_eft(Args _args)
{
CustTable myCustTable;
DirPartyTable myDirPartyTable;
str eft;
int updated;
;
updated = 0;
ttsBegin;
while
select
forUpdate
AccountNum, VATNum from myCustTable
join myDirPartyTable
where ( myDirPartyTable.RecId == myCustTable.Party
&& myCustTable.ADCEFTNumber == " " )
{
eft = '1' + subStr( myDirpartyTable.PartyNumber,2,10 );
myCustTable.ADCEFTNumber = eft;
myCustTable.update();
updated++;
}
info( 'Total updated = ' + int2str( updated ) );
ttsCommit;
}

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

In this case if there is no additional logic connected to your field in case the value changes, you should have used validateWrite() then if return value for that is true, call the doUpdate(). By using update(), you could trigger unwanted business logic such as the one you've experienced.

Before calling update you must always check the standard overrideable methods (insert, modifiedfield, update, write), and also their event subscriptions and walk through the code to see what is the impact of your doing.

Was this reply helpful? Yes No
Verified answer

André Arnaud de Cal... 301,020 Super User 2025 Season 2 on at

Like (2)

Report

There is no business logic in the update method of the CustTable related to the financial dimensions. I do think the problem is caused by using a field list in your select statement.

You used: while select forUpdate AccountNum, VATNum from myCustTable.

This will retrieve only two fields and have all other fields empty (also the DefaultDimension field). On update it can indeed lose all not retrieved fields.

Try the same without a field list: while select forUpdate myCustTable.

Was this reply helpful? Yes No
André Arnaud de Cal... 301,020 Super User 2025 Season 2 on at

Like (2)

Report

Another important note: Test your jobs in a test environment first before applying it on your production environment.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks André, you were right and retrieving all fields is the answer.

Was this reply helpful? Yes No