Not sure if this helps, but I only run the behavior check on the action that initiates the loop. So in your case that would be ‘Grouped: Add Row Loop’. I don’t have a behavior condition on the other two actions related to the looping action.
If the amount of rows in which the loop has to run is not that big, add another action that updates the expression and values that are inside the condition
Thanks, @SkrOYC for taking a peak at it. Would you suggest an action and expression for me that would update those values, please? I presume I would put that action inside the grouped sequence of actions (in between the “Add New Row to Unit” and “Loop Repeat …”)?
The [Assigned Units] column is a virtual column that counts a Select expression. The [Add Rows] column is a static column that the user inputs a value for (if that helps).
My next suggestion is to let us know how [Add Rows] and [Assigned Units] are configured. There is a possibility that the loop repeats prior to those columns being updated, and that will result in an infinite loop (hence the lock up).
I think that in this case the [Assigned Units] column will not update the calculation before the loop is repeated again. The only way I have found to overcome this is to include a select statement in your condition for the loop firing action as this will force recalculate the value for the column prior to repeating the loop.
Add an action between the other ones, before the evaluation takes place, that updates the row where this [Assigned Units] column is. Consider adding an extra column to all of your tables with this purpose. This post explains what I mean
Thank you, Markus. That does seem to be the case. I used SkrOYC’s update method he mentions in this thread and it solved my problem. I imagine your approach would accomplish it as well.
