LongRange Developer Forum

Many of the LongRange example RPG programs make use of '/sharedStates' variables, but with no explanation of what the scope and duration of these variables is.

From experience, these variables seem to persist across sessions until they are explicitly cleared. Is this the case? If I set the value of a '/sharedStates' variable, can I count on that value persisting for days/weeks at a time, until such time as I choose to clear it? I'm guessing these are stored in a user-space type object.

Also, what is the scope of these variables? Again, from experience, these variables seem to be global across all programs for a user, but are they scoped to a user, or are they scoped to all users for all LongRange RPG programs? Scoped to a specific schema for a specific user?

I am hoping this is similar in concept to 'cookies' in the web world, where I can persist preference information for a user, so that I can use that each time the user accesses an application to build the display based upon the users preferences.

TIA

JJ

They persist on the client until LongRange is uninstalled. They are globally scoped within a schema. They are not encrypted values.

When a device has multiple users you could divide up your shared space namespace by using the user profile (or something like that) as a prefix in your names. eg: FRED.LastSearchedOrder, MARY.LastSearchedOrder, FRED.LastPrintSize, etc.

Note how shared values are always exchanged between the client and the server – so you don’t want too many of them.

So another way to do this type of thing is use the device SystemINFO.ClientGUID that was assigned at installation (or you can assign you own device ID at first contact if you choose) as a key value.

Use it (and maybe the user name) as the key(s) to a simple data base table of device and/or user orientated ‘properties’ (eg: the property named “LastSearchOrder” has value “7647474” for User "Fred" on the device with ID = "c6ef-4658-a5d4ce-46783").

Using a data base table on the server has the advantage of being backed up unitarily.
It offers another way to reject contacts from a device reported as lost or stolen.
It minimizes the amount of information being sent between the client and the server - only the key need be exchanged.
It is also accessible to all your server side programs - so your RPG batch programs (for example) can access details in it as long as they are passed the key(s) as parameters.

Mark,

Thanks for the information, and the suggestion.

After reading that these variables are passed back and forth between client and server all the time, I implemented your suggested approach of serializing these variables in a local table on the server, wrapped with procedures 'GetStateValue()' and 'SetStateValue()'.

JJ

Any chance of sharing your code and DDS or SQL?
I think this would be very useful to others.

Happy to share.

What's the process for this?

JJ

I would just copy any relevant code sections to a MS-Word document - along with any screen prints and explanation that aid understanding.
Then post the document as an attachment to the this forum.

For what it's worth, I've attached a document that contains the code I used to implement an alternative to the '/sharedStates' method for saving state values in an AS/400 table. Hope it helps.

It's a very nice example. I had never seen the RPG “template” keyword in use before. It solves a problem that has been concerning me for a while – how to define data structures and field prototypes that use up no storage of their own.

Guys,

In case any LongRange LANSA developers wish to do the same, here is an export for VL of my server side caching. The export contains a File, its fields and an RP with methods to get and set values.

Cheers
Greg