Session Variables Object and NULL

[PointsWell]

If you are using the Session Variables non persisted object to hold the IDs of BOs (instead of placing the BO itself into the SV object) you must set the initial value of these IDs if you rely on auto refresh based on these IDs being set.

For example:

• List of Contacts. Default operation with Records sets SV.ContactID
• Grid on same page generated from a stored procedure using SV.ContactID as an input with the grid set to refresh based on default operation

This causes the grid to repeatedly send the same value and not refresh the grid (or in the example that I was working with a Chart driven by a Stored Procedure).

[nhofkes]

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.