1 2 Previous Next 27 Replies Latest reply on Jun 15, 2017 10:55 AM by gofmp15

    Global fields, the correct choice?


      I use global fields for a variety of things, as I'm sure most of you do. However, I have a particular issue that makes me question whether I should use a global field for this specific reason.


      The main project I work on is for a school. I use a global field to store the date of the first and last days of school. Those two global fields are used to calculate the age of students on the first and last days of school.


      The db is hosted remotely and multiple users use the solution.


      Everyday, the global fields are empty and the students' ago calculation is empty (because the global fields are empty). It's not a huge task to enter a few dates every morning, however, as the users have pointed out to me, the program does a lot of amazing things and it seems odd that each user has to re-enter the dates each day. I understand how global fields are specific to the user, but do wish I could find a solution that retained the data.


      What is a solution that will allow the values for the dates of the first and last days of school to persist even after the file is closed for the night, but also allow the value to remain available to the calculation for ALL records (students)?

        • 1. Re: Global fields, the correct choice?

          Option 1:

          If you take the file down off the server, open it directly in FileMaker Pro or Advanced, change the value of the dates in these fields, then put it back up on the server, each user will see these dates and not need to re-enter them each time.


          Option 2:

          If you set up a one record table with both dates in nonglobal fields, you can use a script performed by OnFirstWIndowOpen to set your global fields (or a pair of global variables) to these values each time the file opens. TO specify new dates--such as for the start of a new school year, edit the dates in the non-global fields.


          Option 3:

          If you set up the same table as Option 2, you can use cartesian joins (Uses the X instead of =) to link in an occurrence of this record's table wherever you need these two dates to be accessible.

          • 2. Re: Global fields, the correct choice?

            Your practice of "storing" data in temporary, user-specific, session specific global fields is poor practice, not updateable, and a guarunteed data disaster. Use a real table with stored values for such things. Often a single record Defaults or Preferences table that holds such values.

            • 3. Re: Global fields, the correct choice?


              1. I do not understand "not updateable." We change the data in the fields whenever we need to.


              2.The global fields are in a real table (in fact, I didn't know that FMP had un-real tables).


              3. I'm also unsure of your ability to predict the future and determine that it is a "guaranteed" data disaster.


              4. I've never had someone be so negative in a reply on this forum.  I understand that is not working correctly and that's why I asked for help.

              • 4. Re: Global fields, the correct choice?

                Thanks, @philmodjunk, I appreciate the help. I'm going to try Option 3.

                • 5. Re: Global fields, the correct choice?

                  What Bruce meant is that you can't update a global field and see the change persist when you host the file from a server. Since the changes can't persist, it's not update-able.


                  I generally use the 2nd option as it can be easiest to implement and maintain. I generally go with 3 only if I need updates to the field to be immediately visible to all users. I'll use a global field if I need some sort of edit capability or if I need to use the value as the match field in a relationship, otherwise, I'll just use a global variable for the purpose.


                  Note that #3 does not use global fields.

                  • 6. Re: Global fields, the correct choice?

                    Thanks for that explanation. I appreciate it. There's so much to learn . . . always.

                    • 7. Re: Global fields, the correct choice?

                      Standard idea is to have a table for preferences and in your case you'd add start and end date for the school year. These would be normal fields so you's create one record to store this data. Now they can be changed as needed.


                      Next you might add two calculated global fields whose calculation is one of the fields mentioned above.


                      Global fields lose their value if another person opens the file but this method would keep one value available.

                      • 8. Re: Global fields, the correct choice?

                        Nope. That is not how calculated global fields work. Edit the Preference record?


                        NO CHANGE to the calc.

                        • 9. Re: Global fields, the correct choice?

                          Which is why I describe using a script to load globals when the file opens.

                          1 of 1 people found this helpful
                          • 10. Re: Global fields, the correct choice?

                            + 1 to Phil on this!


                            An addition though. We use an awful lot of global fields and are sometimes forced to develop away from the server in single user mode (car passenger seat, airplane, train, boat {don't ask!} etc.). The retention of global field values in single user mode can be a nightmare as can running FileMaker Server locally on our MacBooks (locked files for instance).


                            The option we've included in our systems is a shutdown (OnLastWindowClose trigger) script that goes to a layout that contains all the global fields we wish to clear. The script sets a variable using FieldNames ( Get ( FileName ) ; Get ( LayoutName ) ) to list all fields displayed and a second variable to count the number of entries.


                            A loop then sets the contents of each field by name to empty, then returns to the layout we wish to be the default upon opening and is very quick.


                            Any new global fields created can be dragged on to the layout to be cleared and the file is always ready for upload to FileMaker Server with clean global fields.





                            • 11. Re: Global fields, the correct choice?

                              A dedicated preference table with just one record can be used to change the value of a global that persists for all who open the file since the one record persists.


                              Create a calculated global whose value is a data entry field. The global will change when the value in the field changes and it will be the same for all who open the file, even on a network.


                              The graphic shows how to do this for two date fields


                              Global Date Preference.PNG

                              • 12. Re: Global fields, the correct choice?

                                Not so. A calculated global field can be set to change when the value in a field changes which is why they are called calculated. Just make the calculation refer to one field. See my graphic for details.


                                If the global is a calulated global that references a field its value will remain the same as the field. Make the global non-enterable on the layout.


                                If there are more than one record, then this gets messy so make the preference table only one record. The global will use the value in the last edit if there are multiple records which is why there should only be one record in the table.

                                • 13. Re: Global fields, the correct choice?

                                  Also, if the fields are define to have a default value entered, the table's records can be deleted and the new values will be set in the globals.

                                  • 14. Re: Global fields, the correct choice?
                                    Stephen Huston

                                    While global values might be retained even after deleting the records of the table, the global field values become problematic to reference as related fields and in calcs if no actual record exists.

                                    1 2 Previous Next