Global Values not 'sticking'?

[Wickerman]

I've set up an email feature that allows the user to store 'boilerplate' text to be inserted at the beginning and end of a message when a Send email script is triggered.  It's working fine on my desktop version of the file.  However, my client is finding that when she changes the boilerplate text in those global fields and closes the file, when she reopens the file, the changes have not been retained.  Simple text fields, global storage. My client is using the files via Filemaker Server 16.

Can anyone suggest why this would be happening?

[bcooney]

Global fields are not a place to store data. Think of them as temp storage. You need to store these "preferences" in a single record table and set the globals from those values or simply set the globals in a script that is called by OnFirstWindowOpen script.

[Wickerman]

Thank you -- but could you clarify what you mean by "single record table"?   I haven't come across that before. . .  I'm imagining maybe I create a table with these 'boilerplate'  fields in it and related it to the table my layout is based on, so there is no occasion to create new records in it?

Also, could you maybe elucidate why values in global fields wouldn't be saved just as data in 'normal' text fields is?  I'd kind of like to know the mechanism by which this is failing.    I really appreciate your responses.

a.

[comment]

6 hours ago, Wickerman said:

why values in global fields wouldn't be saved just as data in 'normal' text fields is?

The reason for this is that each user can have their own global values. So the way it works in hosted databases is that each user starts with their global fields getting populated by the default values stored in the file, and they can change these for themselves - and only for themselves - for the duration of the session. 

---
An interesting question, which I never got answered, is what happens if a global field is modified by a server-side script.

[Wickerman]

Oh of course -- I knew that once, but it hasn't come up for long enough that I forgot.  So would the approach be to create a new table to hold these 'boilerplate' fields create the first record, and then use an (X) relationship to connect it to the TO my main layout is based on?  I have a button that summons a card window I would base on this boilerplate table and when the user edits the text it will be permanently storing it in the one related record?   Is that the right approach?  

 

Oh wait . . . since the Card Window has its own context, it doesn't even have to be related to the table on the main layout, right?  I think I've got it . . .

 

Edited September 28, 2018 by Wickerman

[OlgerDiekstra]

On 9/28/2018 at 6:16 PM, comment said:

An interesting question, which I never got answered, is what happens if a global field is modified by a server-side script.

That IS an interesting question.

I would expect that it would be the same, considering a server side script modifies a hosted DB, therefore the same limitations would exist where the globals only exist for the session running the server side script and are lost afterwards.

 

[Fitch]

That's correct, a server-side script is the "user" and gets its own session.

[comment]

8 minutes ago, Fitch said:

a server-side script is the "user" and gets its own session.

I think that means that users will be unaffected by the modification, whether they are already logged in or log in after the script has run. But does that also mean that a subsequent script performed on the server will go back to the original values stored in the file the last time it was opened locally? And what about a subscript; is it part of the same session as the parent script?

[Fitch]

A subscript is part of the same session. Scripts called subsequently are new sessions.

https://fmhelp.filemaker.com/help/17/fmp/en/index.html#page/FMP_Help/running-scripts-on-server.html

[comment]

18 hours ago, Fitch said:

Scripts called subsequently are new sessions.

Thanks for clarifying. Pity, though - I was hoping it would modify the value stored in the file. That would be cool.

[Josh Ormond]

If someone needed to change the default value, you can change the field to a stored calculation. Close the Manage Database window, and save. Then reopen, change it back to a global. It will then retain the value of the stored calc for any new sessions.

I still prefer to have a preferences table, and load everything OnFirstWindow open, but this is an option if needed.

[bcooney]

And I prefer to use selector-connector and access this table from any context . 

[Fitch]

On 9/30/2018 at 10:01 AM, comment said:

Thanks for clarifying. Pity, though - I was hoping it would modify the value stored in the file. That would be cool.

Yeah it would be cool if that's what you wanted. Would be very uncool if you didn't want that. The more I think about it, I think it makes sense the way it is.

[comment]

4 hours ago, Fitch said:

it would be cool if that's what you wanted. Would be very uncool if you didn't want that.

Isn't that true for every feature? 

The point is that right now modifying a global field in a server-side script serves no practical purpose - but it could be used to change initial global values much more easily that currently available methods.

[Fitch]

9 minutes ago, comment said:

The point is that right now modifying a global field in a server-side script serves no practical purpose

If that's all the script did, OK. But I've used globals to drive relationships in server-side scripts, for one example. And if I had to worry about those globals sticking around, that would kinda suck.

[comment]

14 hours ago, Fitch said:

I've used globals to drive relationships

That's a fair point. Well, it was only wishful thinking on my part anyway...