9 Replies Latest reply on Jan 2, 2015 11:58 AM by DavidJondreau

    Save global fields from remote users?

    pacoenri

      I have a file share in a external server. When a user remote exits the application global fields are reset.

      I need that if the user is Administrator (although remote user) fields can be stored in the server.

       

      How I can do it?

        • 1. Re: Save global fields from remote users?
          Mike_Mitchell

          If I understand your question correctly, what you'll likely need to do is implement a Sessions table. That table will create a new record each time a user logs in, recording the user's account name and the value of any globals at the time of exit. You can use the OnLastWindowClose trigger to execute a script that can save the values in the globals.

           

          HTH

           

          Mike

          • 2. Re: Save global fields from remote users?
            pacoenri

            Exactly. This is a good solution. But I wonder if there is a direct method for storing information on a server global field, available for other users.

            • 3. Re: Save global fields from remote users?
              Mike_Mitchell

              A common method is to use a "globals" or "common" table that only you control. It has a single record with default values, stored in non-global fields. Then, you use an OnFirstWindowOpen script to set the globals equal to the defaults when a user logs in. Should you need to change the defaults, you change the values in the "globals" table. That way, they're preserved and you don't have to shut the file down on the host.

               

              Mike

              • 4. Re: Save global fields from remote users?
                flybynight

                If the info changes over time, I'd say that Mike's solutions sounds great. Thanks for the idea, Mike! No other way that I know of to accomplish what you are looking for.

                 

                But, if you just want to set the values in the global fields one time, and don't think they will every change, you can't do it while it is hosted, but you can do it by taking the file down, opening it on your local machine, and setting the global fields how you want them. Then put the file back up the server and it will keep those values.

                 

                I recently discovered that the same goes for things like window position/size, status toolbar view/hide, and probably some other stuff that I don't realize. If you set these things before you upload your file to Server, you have less to do on your startup script and less window bouncing around/flicker.

                 

                Hope that helps!

                -Shawn

                • 5. Re: Save global fields from remote users?
                  pacoenri

                  Thank you both. See more easy option Mike. Although rarely changing fields, not very easy to load / download the file to the server due to size future.

                  • 6. Re: Save global fields from remote users?
                    ch0c0halic

                    Shawn is correct, there are many things set as defaults for the file when it is opened locally (non-hosted).

                     

                    One of the most important is the layout the file closes on. I strongly suggest that your closing script goes to a layout that is blank, white, small sized, located in the upper left corner of the screen. When opened over a WAN it will speed up the opening process and provide a clean layout for the user. The importance is not obvious until the WAN has sufficient latency to allow FMP to show this first layout, which it always does!!! Before it can run the open script or change to the preferred layout it must establish a frame of reference (context) for all other operations, which is the layout established on local close.

                     

                    Note that just because you switch to the layout does not mean FMP will save it in the file. A layout change does not require a save of the DB. The close script must also make a change that requires a DB save, like a set field.

                    • 7. Re: Save global fields from remote users?

                      Keep in mind that this mysterious server table is really just a Filemaker File table on the server. The Filemaker Server is an application that hosts and makes available the Filemaker Pro files. It is not a database, just an application (a group of many actually).

                       

                      Global fields were created to act as variables and now that Filemaker has a limited set of variables, global fields are less needed.

                       

                      You can create a table to store global field data and create a record in that table to insert the global field data...or use real fields with a record assigned to each user and pretend they are globals.

                       

                      But the answer you want is this. During use or when exiting the file, store the values in a real field in a real table. Some globals are temporary, some are session oriented and some are to be used in all sessions. Design accordingly.

                       

                      Perhaps the simplest answer is to create two fields, one global and one real. The real field updates to the contents of the global field as it changes. Then when you quit, it keeps the value. If the data is real valuable and you must keep it I would use this script at the end of each script where you need to save the data:

                       

                      Set field Real to Global Field

                      ...

                      Set field Real_X to Globa Field_X

                       

                      Use one set field for each globa/real field combo. Perform the script at the end of each script.

                      • 8. Re: Save global fields from remote users?
                        deephat

                        ch0c0halic wrote:

                         

                        One of the most important is the layout the file closes on. I strongly suggest that your closing script goes to a layout that is blank, white, small sized, located in the upper left corner of the screen. When opened over a WAN it will speed up the opening process and provide a clean layout for the user. The importance is not obvious until the WAN has sufficient latency to allow FMP to show this first layout, which it always does!!! Before it can run the open script or change to the preferred layout it must establish a frame of reference (context) for all other operations, which is the layout established on local close.

                         

                        Can you please explain how the "closing layout" impacts performance?

                         

                        I am working on a solution in FMP13 that will be hosted on FMS13. The solution will be run from Desktop users with a GUI that is designed for a 1920 x 1080 display. The solution will also be accessed by FMGO users (using separate layouts designed for mobile).

                         

                        When I try your suggestion (creating a layout that is blank, white, small sized, located in the upper left corner of the screen) I see some unwanted resizing of windows when the database opens on the 1920 x 1080 displays. I am executing a script upon the first window opening that (freezes the window, goes to the 1920 x 1080 layout, and then adjusts the window to full-screen).

                         

                        Is there any way to prevent this user from seeing this window resizing? It only lasts a split second but I am more of a GUI designer than I am a database expert and it's going to drive me nuts if I see that window resizing every time a user opens the database.

                        • 9. Re: Save global fields from remote users?
                          DavidJondreau

                          It is good practice to close your file locally with the settings you want to be there when it's opened on a host, but it's not necessary to bypass the last layout the file was closed on. The File Options-->Switch to layout option bypasses the "default" layout. This is easily demonstrable by using a related file reference (see attachment). I haven't seen any evidence otherwise.

                           

                          In general you want a clean opening experience and so you should have an opening layout that users see when opening. I use a layout based on my single record Settings table with no fields and the text "Opening...". That layout is set by the File Options...setting. I use an OnFirstWindowOpen triggered script to

                          1) check if it's a server-side script using ApplicationVersion (if it's server-side, a lot of sub scripts get skipped).

                          2) check the SystemPlatform (for windows actions. PCs get Maximized, Apples get Resized to Fit)

                          3) Freeze window...Now users see the "Opening...." text in an appropriately sized window.

                          4) Perform a bunch of subscripts to do things like open a session and load globals and load user preferences.

                          5) Navigate to the central user layout (or last layout user used depending on user preferences).