14 Replies Latest reply on Feb 24, 2017 4:34 AM by siplus

    Protecting Viewed Records

    Vinny

      If I am a layout viewing a record (a customer record for example), I want to protect it from being deleted by another user.

       

      I don't want to open the record, because then it will update it's modified timestamp.

       

      The main reason is that I don't know how to handle the case where one user is "viewing" a customer record, and another user deletes that record.

       

      I would like for other users to be prevented from deletion as long as another user is viewing the record.  The same goes for when a user is viewing a child record of the customer (i.e. contacts) - I don't want a user to be able to delete a customer if another user is viewing a contact record of that customer.

       

      Please let me know if you have any ideas for this.


      Thanks!

        • 1. Re: Protecting Viewed Records
          mikebeargie

          The only way to do it without "open record" to lock it, would be to write a value to a flag field that indicates the record is being viewed.

           

          EG script trigger for OnRecordLoad sets a field called "table::locked" with a value of "1", then users are blocked from delete access for any record where locked = 1. Then another trigger unsets the "1" value.

           

          HOWEVER, that method is NOT reliable since you could potentially force quit an application and bypass a firing trigger.

           

          So I would actually recommend that you use "Open Record", along with "Commit Record" and "Revert Record" accordingly to allow FileMaker to use it's already robust record locking as intended.

           

          There is a function called Get(RecordOpenState) that you can programmatically use to check for a record being locked.

           

          FileMaker Pro 15 Help

          1 of 1 people found this helpful
          • 2. Re: Protecting Viewed Records
            Vinny

            Thanks Mike.  That's what I thought.  I am using the session model for many of these cases, so I was considering adding a non-global field in the session record that tracks a list of any records being viewed.  Then, in the delete scripts, I will check to see if it is being viewed by any sessions/users.

             

            This still leaves the chance of locking a record if one of the user's sessions crashes.  I'm hoping that the session clean up scripts (delete all sessions on first user logging in or delete all user's sessions when logging in if other users are present) will be sufficient to clean this up on a regular basis - worst case, daily.

             

            Just curious, are you then manually updating the modified time stamp of records if you are using open record to lock it?

            • 3. Re: Protecting Viewed Records
              siplus

              Vinny wrote:

               

              I don't want to open the record, because then it will update it's modified timestamp.

               

               

               

              Are you sure ????

               

              (not in my book)

              • 4. Re: Protecting Viewed Records
                mikebeargie

                It will only update if you commit the record. If you just revert out of it no modification is triggered.

                • 5. Re: Protecting Viewed Records
                  Vinny

                  You are correct.  If I open the record, then don't commit any changes, it shouldn't update the timestamp.

                   

                  In an attempt to be short in my question, I incorrectly stated the issue with opening the record.  In my case, I am using some functionality to control the record commits.  I don't know any other way to prompt the user to save or revert on record commit, other than for checking for record open state.  If I open the record, then my scripts will ask the user if they want to save or cancel changes, because it appears to my script that the record has changed with an open record state.

                   

                  I've been trying very hard to implement record saving functionality like that of most windows programs... The big mystery to me is how people are handling this in their applications.  If there is a save button and a revert button, how do you handle it when the user tries to leave a record that is in it's open state?  Automatically save?

                  • 6. Re: Protecting Viewed Records
                    mikebeargie

                    Try Get(ModifiedFields) for checking to see if any changes were actually made to the record.

                     

                    https://www.filemaker.com/help/15/fmp/en/index.html#page/FMP_Help/get-modifiedfields.html

                    1 of 1 people found this helpful
                    • 7. Re: Protecting Viewed Records
                      Vinny

                      Great idea.  Thank you.

                      • 8. Re: Protecting Viewed Records
                        mdenyse

                        An alternate approach would be to mark records as deleted so they stay visible in the database so others can view the records. These and any child records could show a visible indicator that there's a pending delete.

                         

                        At a later time (perhaps as a nightly task), you delete the records when the likelihood of anyone being in the database is low.

                         

                        Obviously this has its own set of issues, but it's one other way to resolve your issue with having to worry about locked records.

                        1 of 1 people found this helpful
                        • 9. Re: Protecting Viewed Records
                          siplus

                          Check the enclosed file. Use the provided buttons.

                           

                          If you open the record, then commit it without doing any changes, the TS WON'T change.

                           

                          If you do change something, it will update, but that's just expected behavior.

                          1 of 1 people found this helpful
                          • 10. Re: Protecting Viewed Records
                            Vinny

                            Thanks for the sample file.

                             

                            When using the "open record" method, I guess my only question would be how you handle the situation when the record is already in use by another user.

                             

                            I don't mind showing or notifying the user of this situation, however more importantly:

                             

                            If user A visits the record and opens it, and user B visits the record, but can't open it - what happens when user A is done visiting the record?  Now user B is in the record without it being open!

                             

                            Should I approach this with a script to detect if the record has been deleted (on record load) and just close the window if the record has changed?

                             

                            I'm not sure how to handle this!  Any thoughts would be greatly appreciated!

                            • 11. Re: Protecting Viewed Records
                              siplus

                              you won't be able to open it if it's opened by another user, nor will you be able to delete the record. But you will be able to view it.

                               

                              Just open the database from another client - or from a copy of Filemaker on your own computer - and see what happens by yourself.

                              • 12. Re: Protecting Viewed Records
                                Vinny

                                I still want the user to be able to view the record - even though they can't "open" the record for editing.

                                 

                                So If user A views the record and "opens" it, and user B views the record, but can't "open" it - what happens when user A is done viewing the record?  Now user B is in the record without it being "open".  User C can easily go in and delete the record while user B is still viewing it.

                                • 13. Re: Protecting Viewed Records
                                  philmodjunk

                                  Don't have the users delete these records ever. Have a "delete" script that changes a status on a field to "mark" it as deleted without actually deleting it. Other users currently viewing the file will still be able to view it. This requires modifying your UI to filter out "deleted" records from relationships and finds but you also gain the ability to "undelete" records that were "deleted" by mistake.

                                   

                                  Another option is to set up a related table where each user's account name and current timestamp is "logged" when the user selects the record to view and which is deleted when the user stops viewing the record. A script run to delete the record checks  that relate table to see if anyone with a recent timestamp is still viewing the record.

                                   

                                  The timestamp helps allow for the possibility that a user gets disconnected or crashes while viewing a record and thus cannot "release" the record that they were viewing.

                                  1 of 1 people found this helpful
                                  • 14. Re: Protecting Viewed Records
                                    siplus

                                    As philmodjunk says, do not allow deletion of records. Allow users to mark a record for deletion and have a person responsible for deletion that looks at records marked for delete and eventually deletes them, after having had a chat with the user that marked them for delete in order to find out why.

                                     

                                    It's not a filemaker problem, it's a company structure problem.