8 Replies Latest reply on Mar 14, 2013 11:39 AM by DrewTenenholz

    Deleting a Preferences Table record

    StanMillar

      Hi all

       

      Looking for a best practices here.

       

      Background: FileMaker Server 12

      Access by FileMaker 12 clients on a mix of Mac and Windows, some local, some remote access.

       

      I am going to create a preferences record for each user who logs into my system.

       

      My main question revolves around tidy cleanup when a user (for example) loses connection to the host. At some of my clients' sites, this can happen several times a day because of the quality of their internet connection.

       

      What I don't want is numerous records for the same user accumulating over a day. I know I can run a script to clean up at the end of the day, but this does not suit the use case.

       

      My thoughts are that I could query the table when a user logs in and if a record already exists, use the data from that instead of creating a new record?

       

      Any other suggestions.

        • 1. Re: Deleting a Preferences Table record
          DavidJondreau

          Well, on log in, you can query the table and if record exists, delete it and start anew.

           

          What is your preferences table storing? Are you creating new records each day someone logs in? Why do you want to avoid multiple records if a user doesn't disconnect correctly (it could be useful diagnostic information)?.

          • 2. Re: Deleting a Preferences Table record
            StanMillar

            Hi David

             

            Thanks for your reply.

             

            My database holds Privacy Act (Aust) sensitive information. For security reasons, I am trying to limit logins to one per user.

             

            I have other diagnostics in place, so don't need the preferences records for that. (Famous last words.)

            • 3. Re: Deleting a Preferences Table record
              LyndsayHowarth

              Hi Stan,

               

              StanMillar wrote:

               

              My thoughts are that I could query the table when a user logs in and if a record already exists, use the data from that instead of creating a new record?

               

              I think I would delete the earlier record then create a new one. Actually visa versa would allow you to have a relationship for that logon name where time is not equal to time and delete all records in the portal.

               

              Reusing the same record could leave a recid trail in cache or such. I reckon better to shed all trace.

               

              - Lyndsay

              1 of 1 people found this helpful
              • 4. Re: Deleting a Preferences Table record
                LyndsayHowarth

                I have other diagnostics in place, so don't need the preferences records for that. (Famous last words.)

                You are covered

                • 5. Re: Deleting a Preferences Table record
                  DavidJondreau

                  Limit to one login per user per day or one login per user concurrently? It's not clear to me how either one of those issues would be addressed with creating records in a preferences table or how successfully addressing them would improve security.

                  • 6. Re: Deleting a Preferences Table record

                    So what you want is a session table ... Using their Staff record works well.  Preference should be one record so the single record is always the one available.  Staff table can hold their Account Name only.  After successful login, account name relates to Staff and loads $$staffID.  $$staffID clears nicely.

                    • 7. Re: Deleting a Preferences Table record

                      ... meaning $$staffID clears and no record to delete. 

                       

                      Also, if you call this process Preferences, which is not normal naming in this field,  you will have to explain "so I don't need preferences for that" repeatedly and if another developer takes over they will be very confused.

                       

                      One solution recently reviewed had LineItems called parts, Products called Inventory. Inventory called Lines and ...

                       

                      Naming by standards is always safest.  :)

                      • 8. Re: Deleting a Preferences Table record
                        DrewTenenholz

                        Stan --

                         

                        Re: User Session Record vs. User Preferences Record best practices when clients are frequently disconnected involuntarily.

                         

                        You didn't explain what you mean by a 'tidy cleanup' when users are involuntarily disconnected.  In that situation, FileMaker Server eventually detects the client is no longer responding, and flushes & unlocks any records or data it has for any records the user previously had open.  You can't really control this part, it is intended to make sure that one disconnected user can't end up locking the system forever.

                         

                        I've worked on a system where users were being dropped (either from poor networks connections, or IWP timeouts), and developed a User Session record system.  It was pretty basic: user name, date/time in, date/time out, OS and FMPro versions, but you could certainly put a lot more information into it, like last layout, last record set, etc.  Then, when a user logs in, look for a recently opened (but not closed) session record, and ask them if they want to continue from where they were before.

                         

                        I guess I'm mostly not clear on what you do during normal shutdown that you want to restore if the user session was involuntarily cut off.

                         

                        Creating a session table gives you the ability to run internal 'usage' data like how many users actually logged in during a given period, how many times they log in, etc.  You could even use it to look for patterns in when/how users are cut off to see if there isn't something you can do to maintain the connectivity.  That sounds outside the scope of what you were thinking.  However, if you have a single 'preferences' record that you destroy/create each time the user logs in, you won't be able to do any of these things.

                         

                        -- Drew Tenenholz

                        1 of 1 people found this helpful