1 Reply Latest reply on May 16, 2011 12:21 AM by RestaurantCharlie

    Storing User Settings

    craig_gee

      Title

      Storing User Settings

      Post

      Hi there,

      My database is hosted by Filmeker Pro 11 client on a small local network with around 8 regular users. I need to store user settings/preferences for each user, including SMTP server settings and a list of which notifications they receieve (I have internally generated notifications for things that need attention from staff).

      I have currently created a table with a record for each user which includes a field that has their account name. I then have a table with a global field that is set in an open script to the Account Name of the person that just logged in. These can then be used to form a relationship and retreive that persons settings from their record.

      Is that the normal way of doing it? It seems like a crazy work around and potentially un-stable, for example I have to make sure I update that global field in my "Switch User" script so if someone else logs in they don't have the previous persons settings. I thought that each user account may have some sort of hidden ID that I could use but I can't seem to see such a thing.

      I guess it would just be good to know if there is a better way or if that's the best I can do.

      Thank you in advance for any advice/help,

      Craig

        • 1. Re: Storing User Settings
          RestaurantCharlie

          Again, to my knowledge, this is the way it goes using FM. And if you think about it, any program has to check specific criteria every time a program is opened or user is changed.

          I store all important user setting in global fields with the startup script. And I have a script called CLEANUP that erases the values to all those fields on the shutdown or when changing users. I also have a script step that checks to make sure that all VITAL fields don't have any values when the file is opened to make sure nothing is carried over from one user to another, and another script step to make sure that all VITAL fields have data in them at the end of the startup script.

          My start up script takes about 1.5 seconds on local network, which considering all the stuff it does, and all the value it adds to the users experience, I think isn't to shabby.