a global field, ...is a field from the table, or is it a field from a record ?
... in other words, the load provided by a global field in a table with 1 record is the same in a table of 1000,000 records ?
FileMaker Pro 17 Advanced Help :
A field that uses global storage (a global field) contains one value that's used for all records in the file.
Read more about global fields in hosted databases.
FileMaker Pro 17 Advanced Help Defining global fields (fields with global storage)A field that uses global storage (a global field) contains one value that's used for all records in the file. Global fields are accessible from any context in the file, even if the field is defined in an unrelated table.
FileMaker Pro 17 Advanced Help
Defining global fields (fields with global storage)
A field that uses global storage (a global field) contains one value that's used for all records in the file. Global fields are accessible from any context in the file, even if the field is defined in an unrelated table.
this is the closest thing to my question,...but my doubt is if the global field increases the size ( load ) of the file as the table grows.
- The global field is a field in the table that is displayed in all ?
- The global field is a field that is created in each record of the ?
context : access,... access privileges from any table
There is only one instance of a global field in the entire file. This instance is replicated for every user that logs in.
I am afraid I couldn't understand the meaning of your diagram.
In my opinion, multiple values of a global are NOT stored, one identical copy per record as that would be an extremely inefficient way to handle the value of a global field, but you’d need to get a Filemaker inc engineer to agree to talk to get a definitive answer.
It is more like "A".
A global field can even be set if there are NO records in the table.
Setting or getting the contents of a global field should not be impacted by how tall or wide the table is.
That said, I would normally put all globals in a "Globals" table (unless it is used as a key in a relationship), but this is just a convention.
A global field holds the same value for all records in a table. Actually, it can even hold a value for a table with no records at all.
If you populate a global field in a locally opened file and then upload that file to FMS, the global field will retain its value until you change it, however, if you close and open the file again, the global field will have its original value.
I have noticed a performance hit when you have a global field in a large table and you use it for an import. For example, let's say you have an utility global field and you perform a 25K record import. For every record you import, the global field will recalculate and show the same value for all records in the target table, so the import gets slower and slower. It's important to leave global fields out of any record import.
A good practice is to start developing in a brand new, 100% empty file, which you upload to FileMaker Server and start developing while the file is hosted. Every time you open your "Golden Master" locally and it crashes, is like when you drop your cell phone. The first time it may look unharmed but if you drop it again it may break in a thousand pieces. On the other hand, any global field you create while the file is hosted, will remain empty when you close the file.
Another good practice is to "cleanup" global fields when you leave a module or when you log out of your solution.
In my solutions I always include an utility table (I call it "Access", you can name it as you wish) where I store my "Environment Variables" like user name, user email, permissions, and whatever I know I'll need for the user session. All those are global fields and I clean them up on logout. I know they'll be empty when I close the file but at some point I'll have to open the file locally and I don't want my file with global fields filled with any data.
You can have a combination of global variables and global fields.
Global variables are much faster because they are held in memory, so you can use them for anything but a relationship argument. I mostly use global fields to populate them with a list of values, which I obtain via ExecuteSQL and then use those values in a multi-key relationship for whatever I need. Once I don't need them anymore, I clean them up.
Hope I answered your question
Best regards and merry Christmas!.
I'll add one cautionary note to Ibrahim's sage advice:
If you ever restore from a backup, then be aware that Globals can hold the values at the time of making a scheduled backup and could therefore become the default data in those globals when the served file is next opened.
Can be overcome by clearing global fields as part of an opening script if you've overlooked them when opening that backup copy of the file locally before uploading it to your server, or by making sure that any script sets the global as it's intended to be used before assuming the Global has the desired value.
Just to recap:
A global field behaves differently in local hosted or server hosted
Its the same value for all the records in a table
its a bad practice to import records without excluding the global fields
The original value its the value stored when the table was closed in mono-user
The initial value resets to the original value everytime the databased is closed
There is no need of records in a table to hold a value in a global field
The value in each global field its different for each user in a multiuser server hosted solution
Its a good practice to have a GLOBALES table that host all the global values
If possible, its even better to replace global fields with global variables
Regards and Feliz Navidad
I can't get why is there such difference on field type,
Truncate Table deletes the contents of global container fields in the specified table but doesn't delete the contents of global fields of other types.
Retrieving data ...