Create a new Variable $$$ which would have a scope of the current FileMaker Session. $ has a scope of a script, $$ has a scope of a file while the new $$$ would be session based.
It would be nice not to have to script this process.
@jbante & @FileKraft: Why? This will not bite you. And there will be no law against not using it.
I can see where this would be very convenient. But, I'm afraid it feels too much like malware bait.
Global fields in a temp table are sometimes a hassle, but they can be used to securely share global data within a multi-file solution.
1. can the OP correct the spelling and tags just so people can find it logically during a search?
Con: I think this might encourage some really sloppy and lazy programming techniques (saving confidential data into a space viewable by any FM application - or for potential discovery by malware)
Pro: for perfectly selfish reasons I am upvoting, I would use it immediately to share international exchange rates between a multitude of open FM apps which need to use the same rates. Does this help with separation model applications?
I can see use cases for $$$vars and am also trying to imagine what security hole might need to be closed. Additional use cases.
Perhaps the scope of the variables should optionally be constrained to the files that are bound together using the File > Mange > Secuity > File Access feature
I do think it would be convenient to have this, and FileMaker has in the past offered us more rope to hang ourselves with. But the security implications are real. For that reason I'm not voting up (but I'm not voting down).
It may be nice to have it built in, but you can have it already via several plugins.
Here is an idea for the security:
sounds a sensible option
as long as you are aware of the security around declaring a session wide variable, there is no reason to not have it.
I would suggest something like how python deals with this:
$$ is very close to $$$ so could easily have a 'session wide' variable declared by accident.
in python you have to declare it global, before you can use it (not declare and use in one go)
so maybe they are declared, then modified, or use a completely different prefix , @var / %var / &var ???
i prefer it tighter not wider - i vote for the opposite - window variables - the scope is just the current window.
(i use window variables with my own weird work around which makes the code difficult for others to understand)
This would be a security nightmare. Just based on the usage of the global variables that I see, it would be bad. A session based variable, that you would also want access to, would be left over when someone opens a local file but did not close FM.
Attaching it to a file, would just cause loads of frustration for many users. Not understanding why a script that relies on it sometimes works, and sometimes not.
Global fields are a bit more secure. And it's not that hard to pass the data around if needed.
Back in the day, I used the SecureFM plugin for application level variables. Security was not an issue as each these variables could be set to only be set or read if the correct password was sent as the second parameter
This worked really well for me and I do miss it.
However, I am leaning towards a single global field in a single record table using JSON to store anything that needs to be accessible to all files in a solution. Just dump the unconnected TO on the graph for each file and all is good to go.
The security things may be a problem, but on Server you can do nice things as one PSOS script can set a value and other PSOS script can pick it up.
PS: See Variables functions in MBS FileMaker Plugin
Sorry, have to vote down. It seems like a convenient way to create all sorts of bugs and security nightmares. Session scope? What does that even mean? Files from the same host? All files opened in your FileMaker Client? Files that share the same account name/password? When do the vanish? How to secure against injection from other files (just open a local file and write into a global var?). How to protect them in Data Viewer?
Retrieving data ...