I use global fields a lot. They are great in so many ways but especially as they are unique to the individual user.
I first learnt the power of them when as a new FM user I set up a portal filter using a normal field with a drop down list and then discovered very quickly that user’s screens were changing in front of their eyes as others used that portal at the same time. Chaos. It was easily resolved with a field set as a global field. Manage database > select the table/field > field options > tab:storage > tick – use global storage.
• Not only is it unique for just that user
• but it is still valid whatever found set you are looking at
• and it doesn’t need to be in the table that the layout is based on
• and you don’t need a relationship to it. That’s why often a table is set up to store ALL global fields, wherever they are used.
• Beware though, if you set up one generic field called date_g you might get the same issue as above using it for two different reasons ie Date_Start and Date_End!
I use global fields for capturing form entries. eg username, address; or a choice from a checklist etc, where I want to use the info but not necessarily create a new record.
One thing though. You can’t enter data into them on a layout if your found set has no records!!
I have a simple user interface. Basically a find that any member of the public can use which gives limited info in return. Hopefully enough for them to register to get more info. However if their return is 0 records. They can’t fill in the form’s global fields.
The way I got round that is to include one record with a full stop ‘.’ in an obscure field and find that so one record always shows. But being a ‘blank’ record it’s not obvious.
As an extra catch all. If there’s no record with the ‘.’ for some reason. (I must confess I deleted it once clearing out blank records!!) I have another if get(FoundCount) = 0 and create a new one.
