Take the file down off the server.
Put a value in the field manually or by script.
Close the file and put it back up on the server.
Set up a non-global field in a record in a table that corresponds to your global field. Use the OnFirstWindowOpen trigger to perform a script that sets the global field to the value of the non-global field.
Don't use a global field. Use the Non-global field from 2 above, but use a cartesian join and possibly multiple occurrences of that single record table to make the non-global field globally accessible to the scripts and calculations of your solution.
There's several key differences between 2 and 3:
2 is easiest and fastest to implement as you don't have to build in a bunch of new relationships. But any changes to the non-global field will not be visible to other users until they close and re-open their file (or run a script specifically to update the global field.) 3 can be a lot more work and add a fair bit of extra complexity to your relationships graph, but changes to the non-global field's value will be immediately visible to all users.
So, with my solution, in the original solution, I had Table A that had a hundred or so Calculation fields and because of that it was dramatically slowing down the solution. So, in this new one, I was planning on creating a Global Field for each Calculation field and just storing the original calculation in the Global Field, then changing the Calculation in the Calculation Filed to "Evaluate ( GlobalFieldOne )".
So, it wouldn't calculate until you manually updated the GlobalField. For example, FieldA is a Calculation field whose value is Evaluate ( FieldB ) and FieldB is a Global Text Field that has FieldC + FieldD + FieldE. That way FieldA, which originally had FieldC + FieldD + FieldE, wouldn't have to calculate that on every login. Does that make sense? What would you recommend?
First, with that method, you don't need evaluate and you don't need the calculation. Every place where you need that value, you'd simply reference the global field. But you'll need to store that calculation result in a nonglobal field and then set the globals to the value of that non-global field each time that the file opens. That's Option 2.
Or you reference that stored value in the non-global field via the cartesian join base relationship. That's Option 3.
And note the differences in how soon other clients would see an updated value from that nonglobal data field.
A trick that I may use on occasion:
Make the field "auto-enter" (by calculation).
Set it to Global storage.
I like to place these in a table with other globals only, so:
delete all records
create new record
With only on open script trigger, IF these values need to "refresh to default".
Deleting all records does NOT clear globals, even if they are set before the file is hosted. But it will use any auto-enter for new records. I may use this trick when I cannot remove a file from server to "reset".
Just to clarify, this only sets a value for the current client so all clients still have to do this to update their globals when the file opens for them, correct?
So it's like option 2, but without the need for a non-global field to store the value.
This is "refreshed" when needed. YMMV
Understood, but the refresh happens in a client context. The delete/create won't cause new values to show for current users until they close and re-open.
Not criticizing, I see the advantages, just making clear what has to happen.
Yes, in client context. But this may help OP who has calculation fields and needs to convert. Make as auto-enter global fields and the calculations are preserved until something else can be done.