First edit: It was suggested my original post was not clear enough for my purpose… so I am adding information in the hope of being clearer.
Second edit: corrected a few typos.
I am doing a bit of research on the topic of global fields. These seem unique to the FileMaker platform… that's what I am checking. Forget the under the hood implementation. Let's look at this strictly from a FileMaker developer's perspective.
A global field is a field whose global storage option is set. All but summary fields have the option to set the storage to global storage. A global field is accessed like a field in code and on layouts, can be used in relationships, is part of the security model and can be used in exports and imports. It holds data and this data can be stored (more on that later).
A global field differs from a regular field in many respect. Its data belongs to a table instead of a record (still from a user's perspective). It is never indexed. Modifying one locks no record. Data storage depend on whether the database file is hosted or not: unhosted databases store global field data; hosted databases do not.
Let's forget why the global storage option was created, why someone would want to use a global field or how someone could code equivalent outcomes in other languages or platforms. I am not looking for explanations or workarounds. I am interested in one thing alone.
Do you know of any other database platforms out there that have a similar construct (yes or no)? If yes, which ones (product names please)?
There! I hope this is clearer. Thanks for your help on this topic.
Hi David (@bdbd), glad to see you posting here. I clicked on your profile only after writing my answer. Obviously you won't learn anything from my post. Curious to see what others will say.
I don't think there is a perfect equivalent in other popular DBs, but you don't have to go that far to find constructs that share a lot of the same properties.
E.g. System variables / Global system variables in MySQL. They can be set and retain their value similar to how we can do so by closing a hosted file, setting a global, and re-hosting.
The initial value exists for all new user sessions but not users currently logged in. This is similar to how FM globals are user-specific, and not shared by multiple users.
I think FM's implementation of this idea is a bit goofy, but the concept is similar. Are you exploring the nuanced differences between these constructs, or just the general concepts?
In order to say whether another technology has a Global Field Equivalent, we have to boil down the essentials of global fields in FM and get a good definition. For example, is it important that global fields in FM live inside a specific table, or is that more incidental and not really important?
You are making me realize that my original post remains too vague. Let's limit the "other database platforms" to similar platforms (4D, for example). Comparing environments like LAMP (for example) to FileMaker is like comparing atoms and apples. LAMP is such a flexible environment that very different constructs can serve the same purpose.
Soooo… to answer your question… it is important that global fields live inside a table. Let's not compare fields and variables.
Would you mind sharing why you are asking the question or what makes you ask the question? I could make it easier to understand what you want to achieve and consequently how to answer. I don't quite understand why it is important that this mechanism be implemented in tables and why the comparison to variables is not useful.
Sorry! Can't answer why at this time. I am doing a bit of research on the topic of global fields. These seem unique to the FileMaker platform… that's what I am checking.
I think that's a fair distinction. I don't know much about 4d or similar products. I wanted to add one more frog to the soup and say that it might be relevant to figure out why fields and variables aren't comparable. E.g. global fields in FM are stashed in client memory, like variables, but can be used in relationship definitions and controlled via security. So global session vars in MySQL are actually more like FM global fields than FM global variables.
That said, I know we're ruling MySQL out of the conversation so I'll leave that frog alone.
I can't speak to the best approach for your research, but it feels like it might be useful to draw a feature table comparing the comparable constructs in various platforms, kinda how SaaS websites show the different features for different tiers.