Obviously a bug. [_thisrow_before].[Col]<>[_thisrow_after].[Col] expression not working

[Koichi_Tsuji]

Im pretty much sure this has been working before. So my quick conclusion is it is a bug, which is critical with us.

With the app formula for normal physical column we pass the formula like

[_thisrow_before].[Col]<>[_thisrow_after].[Col]

When [Col] value is changed through the form, this expression should have returned TRUE. However, it does not work in that way for now, obvious bug.   I need a quick fix.

We have been placing such a column with this formula to evaluate the target column is changed through the form by the users. If it is true, we fired the action on form view save event.

But for now, it breaks all the previously set up arrangement, as this expression is not working as expected and it used to work.

@Steve 

[WillowMobileSys]

Is this issue happening in the Bot trigger condition or inside of the column definition itself?  

EDITED: Let me rephrase - Is it happening in BOTH -Bot trigger condition and inside of the column definition? 

[dbaum]

FWIW, I successfully used (as recently as ~10 hours ago) this type of expression in an automation event condition.

[Steve]

If Blank value comparison mode is set to Legacy, the comparison will not behave intuitively if the expression to the left of <> evaluates to a blank value. If using Legacy, your expression must explicitly handle this blank value.

I don't believe [_THISROW_BEFORE] and [_THISROW_AFTER] work in the Only if this condition is true expression of an action.

[Koichi_Tsuji]

---

@Steve wrote:

I don't believe [_THISROW_BEFORE] and [_THISROW_AFTER] work in the Only if this condition is true expression of an action.

---

That is correct. [_thisrow_after].[Col]<>[_thisrow_before].[Col] type of the expression has not been working in the action Only IF setting. 

However, the  same expression should have worked in app formula for both normal/virtual column. SO i m claiming this is a bug.

I tested further to ensure this is an obvious bug by passing the same expression to reset on edit expression field.  Lets say Col2 value is set back to initial value when Col colum is changed. This is no longer working neither.

So @Steve  This is a bug in expression parser on the client side.

@takuya_miyai 

[Koichi_Tsuji]

The same expression for event condition (automation trigger) properly, but not working on client side. It is getting more obvious the expression parser for the client side is broken now.

@dbaum @WillowMobileSys @Steve 

[PatW]

Thanks for raising this!  Do you have a specific example that you can share? I want to make sure we are addressing your issue specifically instead of some old longstanding behavior because I seeing some weirdness with [_THISROW_BEFORE] and [_THISROW_AFTER] like the Only If condition like you mentioned.

[Koichi_Tsuji]

You can test this with your own app easily.

I observed the same problems years years ago and the appsheet dev team fixed the problem to let [_thisrow_before].[Col]<>[_thisrow_after].[Col] expression should work in AppFormula for column as well as re-set on edit field.

However, it looks like the same problem persists.

On the workaround for now is to remove [_thisrow_after] and twist the expression onto ; -

[_thisrow_before].[Col]<>[Col]

Strangely, this expression still works, but not a fancy workaround.

[Adam-google]

Hi Koichi, I checked what's happening. When [Col] is changed, the form tries to update AppFormulas that have a dependency on [Col]. It looks like the issue is the version with _thisrow_after is not recognized as having a dependency on [Col]. This is why the alternative of using [Col] directly still works. I'm trying to determine now if something about this has changed recently. 

I would say that if you're only looking to compare values in a form view, it may be better to just use [Col] directly. The client code makes no distinction between [Col] and [_thisrow_after].[Col] when resolving the values (the dependency tracking is determined by the server when the expression is compiled). I believe the only place [_thisrow_after].[Col] value can diverge from [Col] is in automation where [Col] refers to the value sent by the client in the add or update and [_thisrow_after].[Col] refers to the value read back from the data source after the add or update has been written to the data source. If the data source is a Sheet with sheet formulas, it could capture the updated state of the sheet formula. But this is a pretty niche application, and in pretty much any other situation it's just going to be the same as [Col].

[Koichi_Tsuji]

@Adam-google 

Thank you for your involvement and providing the comprehensive comment, and background reasons. Yes, my own workaround for this sicutation is just eliminate [_thisrow_after] expression on form view settings, and use the direct quote for the column value by passing column expression simply [Col] , instead of [_thisrow_after] .[Col]

For the majority of people, it could be niche use cases, but for me privately, I do use this trick quite many times.

If [_thisrow_after] is only working on the server side alone, why dont we ask Expression Assistant to return error? That could be the most useful and ideal solution for all of us.