I found another issue with the non-persisted session variables object, which may or may not be related to the post by PointsWell.
You can't use WAS CHANGED to check whether any attribute of the SV has been changed by the user - neither in the update rules of the SV object nor in a process that is called from those rules. In other words, the following line
Code: Select all
If SessionVar.Attribute WAS CHANGED Then DoSomething
always results in TRUE and therefore the action being taken, even if actually nothing has been changed in the variable. Furthermore, it seems that OLD_VALUE(SessionVar.Attribute) results in a NULL value.
Perhaps the background is the fact that the object is non persisted. Anyway, it implies that you can't really implement rules or actions that are triggered upon a change in one of the variables stored in the SV object, because there is (as far as I can see) no way to check that there is a change. Of course there is the workaround of storing a copy of the data in a persisted object (for example the LIRU) and then comparing the two, but if you create a copy then what's the point of having the data in the SV.
I guess the SV may still be useful to store temporary data that is shared between different processes and/or objects that do not have the same Context. But I had hoped that it might be a bit more than that.