How to avoid error "BO has been changed by another user"

[nhofkes]

I am struggling with the error message "[BO] has been changed by another user. Please get the latest version of the data and try the operation again." when saving the form of that BO.
The situation is as follows:

• I have a BO 'Transaction' which owns multiple 'LineItems'.

• There are BO rules for both the LineItems and the Transaction. In some cases, the Transaction BO rules are updated following changes in the LineItems, for example if there are LineItems added, removed or changed.

• There is a form for the Transaction which also shows the LineItem as a grid, which is editable.

• After editing certain LineItems in the grid that result in the Transaction being updated (because of the business rules), I always get an error message when subsequently trying to save the Transaction.

I understand that, strictly speaking, the Transaction is indeed changed, although I wouldn't regard this as being 'by another user' because it is by the same user that is trying to save the form. I also understand that the error can be avoided by first (manually) refreshing the form and then saving it. However, I don't want users to have to refresh before save, there should simply be one save button that does the job.

So how do I ensure that this can form can be saved, when there are changes as a result of the BO rules?

I read somewhere on this forum about the possibility to create a temporary BO, copy all data from the 'real' BO to the temp BO, then edit the temp BO, then copy everything back to the original BO upon save. That may be a solution, but it would be a lot of work because I would not only have to copy all direct attributes but also all of the references (in this case the LineItems) from the one to other and back again, so it is hardly an viable option. I am hoping there is a simpler solution. Presumably this situation where a BO is changed by its own business rules is rather common, so I can't quite understand why it must result in this error.

[BLOMASKY]

A couple of choices.

1). There is an action "COMMIT TRANSACTION" (Which Vlad does not suggest using) that will Commit any open transaction. This might help

2). You can control the type of SQL transaction (Isolation Level) in a process, so by moving your logic from a rule to a process, you do have more granularity as to the type of SQL transaction.

(I personally use choice 1 a lot).

Bruce

[PointsWell]

A few questions:

1. The Transaction BO, does it have elements that are editable after it has been created? I have similar BOs but once the header record is created I only open the form using html references to the attribute not the actual field widgets.
2. The business rules that you have for each Transaction and the LineItem, do they have to run EVERY time.

Making a change to a LineItem BO related to a Transaction is affecting the Transaction.pmLineItems, if you BO rule is unconditional e.g.

Code: Select all

BO.attribute = BO.attribute1+100

this will run EVERY time the BO is modified, whereas

Code: Select all

IF BO.attribute1 WAS CHANGED THEN BO.Attribute = BO.attribute1+100 

only runs the rule when the condition is met

Without seeing your rules or your log it's hard to make a recommendation, but the way to identify it is to either

1. switch off rules and test which ones are running unnecessarily, or
2. Review the log when this is happening

Bear in mind if you've got a rule on LineItem that touches Transaction (eg update Transaction.Total when LineItem was changed) then it will be more difficult.

[nhofkes]

1). There is an action "COMMIT TRANSACTION" (Which Vlad does not suggest using) that will Commit any open transaction. This might help

I tried to put COMMIT TRANSACTION in the process that is run after the Save button is clicked, but it didn't help. That point isn't even reached, because the save action results in the error before the succeeding process containing the COMMIT TRANSACTION is reached. I also tried not to save the form but go directly to the process, and then do the COMMIT TRANSACTION. No luck.

Or do you mean that I should put COMMIT TRANSACTION in the BO Rules?

[nhofkes]

Bear in mind if you've got a rule on LineItem that touches Transaction (eg update Transaction.Total when LineItem was changed) then it will be more difficult.

This is exactly the situation, although the rules are not in LineItem but in Transaction. As an example:

Code: Select all

If TransactionLineItem FROM Transaction.LineItems WAS CHANGED  AND ChangedTransactionLineItem.Number WAS CHANGED  Then 
INCREASE Transaction.TotalNumber BY ChangedTransactionLineItem.Number-OLD_VALUE(ChangedTransactionLineItem.Number)

The business rules that you have for each Transaction and the LineItem, do they have to run EVERY time.

Making a change to a LineItem BO related to a Transaction is affecting the Transaction.pmLineItems, if you BO rule is unconditional e.g.

Code: Select all

BO.attribute = BO.attribute1+100

this will run EVERY time the BO is modified, whereas

Code: Select all

IF BO.attribute1 WAS CHANGED THEN BO.Attribute = BO.attribute1+100 

only runs the rule when the condition is met

The rules are conditional. So they do not run EVERY time, but very often.

switch off rules and test which ones are running unnecessarily, or
Review the log when this is happening

I think I know what rules are causing the issue. I can remove the rules, but then the Transaction object is no longer updated automatically. Of course I could do that in a process, but as mentioned elsewhere that is less elegant and can create concurrency issues.

The Transaction BO, does it have elements that are editable after it has been created? I have similar BOs but once the header record is created I only open the form using html references to the attribute not the actual field widgets.

I am not sure that I understand the question. The Transaction has an attribute TotalNumber, containing the sum of the numbers of all LineItems. This isn't editable by the user but is updated by business rules.

[PointsWell]

If the Transaction BO cannot be directly edited by the user after it has been created and the only update that is being made to the BO is via business rules then you do not need to save the form just close it.

[nhofkes]

Apologies for the misunderstanding. It's a combination of both: some fields are editable, such as 'description' and 'comment', while other fields such as TotalNumber cannot be edited but are updated through business rules.
So when the user modifies one or more fields that are editable, I need to save those changes somehow...
What I have not yet tried is to switch on "Save form on focus loss" for all of the editable fields on the Transaction form. I vaguely remember that I tried that earlier, but it resulted in a full refresh of the form which creates a flicker of the screen. So if the automatic save on focus loss would help to prevent the error, I would like to switch off the autorefresh in that case, if possible.

[PointsWell]

I think you are going to have difficulty in fixing this due to there being two competing changes to the BO, via the UI and via a rule watching an external relationship.

Perhaps put the comment and description into a peer single relationship with the Transaction which would allow the comment to be changed without affecting the Transaction BO.

[nhofkes]

Thanks Pointswell. I believe I have fixed it now by the following changes:

• I removed all BO rules in Transaction that updated transaction totals based on changes in line items
• I added the simple rule "Transaction.TotalNumber = SUM TransactionLineItem.Number WHERE (TransactionLineItem IN Transaction.LineItems)", but selected "Don't check referred"

Upon saving the form, the total is automatically recalculated. I know that this aggregation is now unconditional so executed everytime that any change is made to the Transaction even if there are no changes in the line items. But adding the condition 'IF Transaction.LineItems WAS CHANGED' didn't work, presumably because any change in the line items is already processed and the Transaction is in solid state again by the time that the user saves the form.