Tony, prepare 2 fields, one normal container field and one global container field.
In your startup script, load the global container with data from the normal container.
You will have to unhost once to clear the global container to have it empty at startup (the above will still work, but sort of best practice)
ps I think usbc (below) is right, it is not just best practice but you need to clear the field in a non-hosted file first.
Thanks, but isn’t this kinda an aspirine solution ?
You’re not really uploading the new pic in the host this way.
You’re loading in each individual session the globals from a normal container.
Maybe this is the only way to do it ?
If so, where do you then put best this normal container?
In the first record of a database?
Or in a separate tale?
Van: psijmons email@example.com
Verzonden: zondag 22 september 2013 21:23
Onderwerp: Re: Change a global container in the HOST without having to unhost the file?
Yes, a separate table with only one record is a common way to store images that you can use across all tables once they are in global containers.
Once you fill these on a non-hosted developers copy, they are fixed once you start hosting that file.
when you want to be able to change this somewhere down the line w/o taking the files off line, filling it from a normal field will work well.
Make sure you fill this with the actual image, not just a reference to that image.
I'm pretty sure the answer is no. Global content when a file is uploaded to the server are persistent (for good or evil).
I include a one record table (Preferences) for that purpose. For graphics, this remains one of the few uses for repeating fields.
Maybe someone knows another way like using a webviewer, etc. but this method has become my habit.
Actually, globals don't work so well in a multi-user environment.
And as you have discovered, a global is actually local for a user, kind of.
This is the way globals actually work. And the way they were designed.
My advice is to store the logo in a regular container field in a one-record table that can be used for other preference data as well.
If you then need to actually have the logo in a global field, you can always have a startup script that puts the logo in a global field.
If you can, you could make a simple relation from each table to this "Preferences" table. You could use a "Cartesian" relation (the little x at the bottom of the poopup list of relation types), then it won't matter what fields you put on either side.
THe benefit of the latter is that you don't need to put it in startup script and the change of logo will be updated more or less on the fly for all users.
Stefan Schutt, Mouse Up, Finland
created by firstname.lastname@example.org in Advanced Discussion - View the full discussion
I'm using a global container for the company logo in a database.
For marketing reasons, the logo changes from season to season ; sometomes from month to month.
Changing it in a user session (running on FMA12, off the FMServerAdvanced12 host), won't chage it in the server session, but only in the user's own session.
So at next logon, the logo is back to the one that was set in the host.
Is there a way during the user session (so withouth having to unhost the file) to change the container field in the host ?
(Would be ok if the refresh at the other users would only be done at the next logon ; so the next morning e.g.)...
Reply to this message by replying to this email -or- go to the message on FileMaker Technical Network
Start a new discussion in Advanced Discussion by email or at FileMaker Technical Network
Manage your email preferences.
FileMaker Developer Conference 2014 • San Antonio, Texas • July 28-31 • www.filemaker.com/devcon
That was possible in FMS 11 and before, but that option is sadly removed in FMS 12 (bug?)
In FMS 11 you could put a picture in a normal field (as explained above) and using a server script move that field on the server to a global field and that global field would stick to that value.
Ruben van den Boogaard
It has been a standard procedure to have a one record settings or preferences table. The practice, as psijmons said in his first reply, is to have 2 fields for each preference. One stored - one global. However, i disagree with the practice of loading the global's when the file is not hosted. This is unnecessary and really a pain when you have to change an icon or logo.
The global fields can be loaded on startup of the system. I simplify this process by setting an auto-enter calculation like this...
CompanyLogo - container - Global, auto-enter = Case ( gGlobalSettingsTrigger ; zCompanyLogo )
zCompanyLogo is the stored field. Just set gGlobalSettingsTrigger to a value and commit the record and all the field will load the stored image to the matching global. The only caveat is if you use a repeating field, as I do for Icons, you have to set each repetition explicitly.
The other advantage of this method is you don't need any relationships to the setting table. It just has to be on the graph to access the global fields.
I use a table of standard values for Global fields when working with a hosted solution. The fields in this table are regular text, numeric and container fields. This table usually has one record, or one record per user. The startup script goes to a layout based on the this table. The uses setfield to set all of the global fields from the corresponding values in this table. For specific values per user, you can have it select the useres record first and then set the global values. Since the destination fields are all Global you can set them from any context.
Have a layout that lets the administrator get to this table. He/she can then update the values in the fields. Next time a user logs in they will get the new value in the global field.
You can enhance this a bit by using a blank layout to get to the values in the source table for the Globals. Have your OnLastWindowClose script go to this layout and you OnFirstWindowOpen Script FreezeWindow. The after all the values are set and you have landed on the Users desired layout, refresh screen.
Here's how I have handled this for use in a hosted multi-user environment to change a global graphic:
Use a 1-record prefs table and use 2 fields for containers. Make one of them stored, and make the other a global (or, if in a valid relationship, an unstored) calculation which references the content of the stored container.
This allows you to update the graphic as needed in the stored record-field, while the calc field will return the current image for all users during their sessions.
This doesn't require any scripted updates of a global during sessions.
If your logos are really seasonal, you could even have the calculated container reference the repetition to use based on current date, or, if not using repetiions, chose which of several stored fields to use for the calc result based on date -- then you don't have to update anything manually unless the logos are revised overall rathern than just by date. If they do get revised, you can then preload them in the correct fields and they will appear for the currect dates when their time comes.
I think you have many good suggestions. But, you've also specified " . . during the user session . . .".
I take this to mean change the logo image while the user is still in the file. Not just on login and even if he leaves the file open for a week. To do that the logo display field must not use global storage but needs to be unstored so it updates automatically.
Since the logo can change monthly I suggest using 12 logo images:
Use a preference table with only one record. This defines values for the system, like the company logo, name, or maybe the start of their fiscal period.
Create two fields in the preference table.
1. A container field "logo" with 12 repeats displayed.
2. A calculation field "Unstored, recalculate as needed" with result Container =
GetRepetition ( logo ; MonthNumber ( Get ( CurrentDate ) ) )
Put each months Logo image into the appropriate repetition. Any one image may be in there as many times as you require and can be changed at any time. This will update everywhere and does not rely on a script or
Create a cartesian join from each TO assigned to a layout where the logo must be seen. Use the calculation field to display the Logo.
If you need the logo to change at something other than the first of the month you can change the Calculation to use additional criteria, like day of week or day of month, to for example change on the Sunday following the fifteenth of the month.
stephen, I liked your solution, however is not working in a multi user solution.
When user 1 changes the company logo in the container field of the preference table (1 record), the global calculation field changes in that record, so all's okay.
In all the layouts of the other tables (referring to the global calculation in the preference table), changes in the company logo are happening aswell.
However other users then get a blank field in all their layouts where the company logo was ...
Am I doing something wrong?
The calc result probably needs to be set as unstored rather than global storage, so it will resolve whenever it becomes needed.
This may require that you set up a Cartesian [X] join relating the single-record table to tables used as base TOs for layouts on which it appears. This should also remove the "global" issues for other users and allow the refresh during user sessions in progress when the stored container field content is updated. A bit more work in the schema, but that should solve the problem.
I think this will now be a stupid question, but in the single record table, there are only 2 field :
companylogo (the container field)
zcompanylogo (the calculation field)
since no relation can be established with a container field, how do I make that cartesian lnk? Should I create an unused text field?