The normal method for doing something like this is to keep a list of record IDs that are "on" in a global field (or variable) and use a script to add / remove the ID values. That way, each user has a list of record IDs that are "on" available at all times, and you can tell if the current record is selected by using FilterValues.
Here's a Custom Function that adds or removes a value to / from a list. I use it for this functionality.
// AddRemoveListItem (theList; value)
// Author: David Head, uLearnIT
// theList: standard return separated list
// value: text
// this function will add an item to a list if it does not already exist; otherwise the item is removed from the list
novalue = IsEmpty ( FilterValues ( theList ; value ) ) ;
listminusvalue = Substitute( "¶¶" & theList & "¶¶"; [ ¶ & value & ¶ ; ¶ ] ; [ "¶¶¶" ; "" ] ; [ "¶¶" ; "" ] ) ;
listplusvalue = List ( theList ; value )
If ( novalue ; listplusvalue ; listminusvalue )
I am thinking in the similar direction...
The problem is how to show that value (checkbox) by each data record specially if the number of users will be high.
You use an unstored calculation for this purpose. I normally do it with Conditional Formatting, but you can use a field. Something like:
Case ( not IsEmpty ( FilterValues ( table::globalFieldWithSelectedItems ; table::currentRecordID )) ; "1" ; "" )
This will be a "1" if the current record appears in the list, or empty if not. You can put this into a field and use a checkbox with a value list of "1".
Alternatively, you can use Conditional Formatting to change the fields on the current record to a different color, boldface, whatever. This has the advantage of not putting a field in your schema just for display purposes, but might not be the look you want.
Just a warning. Calling a field a "global" is kind of misleading. To a great extent it would be better to call it a "local" field, since its value is unique to the combination of user and session. If you have a global field with value XYZ on the host machine, and a new guest user (say, Bob) logs in, Bob initially sees the field as having value XYZ. Suppose Bob changes it to ABC. It remains ABC for Bob (only), for that session. Bob eventually logs out (or gets disconnected). The next time he logs in, the value of the field has reverted to what the host machine thinks it is, namely XYZ. Meanwhile, any other user (say, Sue) can insert the value PQR into that same field, and PQR is what she will see (for that session).
I realize that this isn't much help for your specific problem, but it might save you from trying to implement a solution that's doomed from the outset.
I'm not sure what you're trying to get to here, Richard, but that's exactly what the OP needs: A way to track data per session, isolated from other users.
If you're worried about server values being retained, then you script clearing it out as part of the opening script or when you navigate to the specific layout.
I use this solution all over the place. It's certainly not "doomed from the outset".
I've worked with users who assume that, once they change the value of a field, it'll stay changed. It's not an unreasonable assumption, but it's not the way FileMaker Pro works when it comes to global fields, and I wanted to caution the OP not to expect it to.
I understand well how global fields behave. The problem was I didnt know how to name the thread and additionally I wanted more people to participate. That was the reason for such a "simple" title.
I think "local field" is not the best option, much better would be session field / value in a data record.
If a DB is hosted on a server, the value of a global field on a startup of a solution will allways be the same as locally before file was uploaded to the server...
It can be changed in startup script...
I wanted to do something similar with related table.
Which approach is faster, what do you think?
I have no idea what you mean. Use a related table for what?