3 Replies Latest reply on Jun 27, 2013 11:29 AM by philmodjunk

    Preferences: Best Practice



      Preferences: Best Practice



           I have been using a table 'system preferences` to set system preferences across my solutions.  The table contains user data such as Company Name, Logo etc etc.

           Originally I used a single record with a simple key (1) and linked to this table in a traditional relationship.  The table has sometimes been in the form of an external file.

           More recently, I have changed preferences to contain global variables.  The benefit is that my table stucture is much cleaner. There have been problems however.  If the file is hosted using FMS, global fileds can only be modified on the server.  Changing via an FM client has no affect.  

           I am also uncovering problems with Mirror Sync.  It doesn't like globals.

           Any thoughts or feedback on which is the correct or best practice are greatly appreciated

        • 1. Re: Preferences: Best Practice

               You seem to understand the issues quite well. You have two basic options:

          1.           Make your preferences data accessible via "match to everything" type relationships. (use the X operator or "ye Olde 'One'" relationship)
          3.           Put the preferences data into global fields.

               With the second option, you can set up a script that loads the global fields from non global fields when the file is first opened to make it easier to update the values.

          • 2. Re: Preferences: Best Practice

                 FWIW, Phil's option #2 is what I have found most robust.

                 Use the globals, but reload those globals on every login, for every user right in the startup script.  In that way, someone messing with the hosted file doesn't break it.  It also gives you the opportunity to change the globals from a client...change the non-global field and now every login afterwards gets the new value in a global field...without needing to ouch the server.

            • 3. Re: Preferences: Best Practice

                   I tend to use 1. when the needs of the project are such that I don't need to link to the preferences table very often and switch over to two as the need for accessing that data becomes a truly global need. (Somestuff may only need to be accessed once during opening and other stuff you need access to all over the place and all the time...