3 Replies Latest reply on Oct 4, 2013 1:47 PM by Arild

    how to know if records in a found set have any open/uncommited records (server/client)

    rothdavid

      I'm updating a script that updates values on a main record that has child records. Account Profile with add'l contacts associated to it.

       

      User A makes a change to the Profile and the script thru GTRR gets related contacts and does a replace field contents calc.

       

      Is there a way I can test if any of the child records are actively open by another user who may be connected and have one or more of these related child records open and editing it?

       

      Looking at Get(RecordOpenState) only evaluates the current record in the set.

      Testing this function Get(RecordOpenCount) doesn't seem to capture a record in an active modified state when I test it having it open in another window, with unsaved text entered into a field, cursor still in the field.

       

      Any advice on a way to test for this would be greatly appreciated.

       

      David

        • 1. Re: how to know if records in a found set have any open/uncommited records (server/client)
          wimdecorte

          All Get functions are user-session specific so you would not know if another user has a record open.  The only way you can find out is to explicity open each record and test for any errors.

           

          If you absolutely must update each client or none at all then you need to look at the transactional model as described on modularfilemaker.org

          • 2. Re: how to know if records in a found set have any open/uncommited records (server/client)
            rothdavid

            Thank you, I'll be checking out the transactional model.

            • 3. Re: how to know if records in a found set have any open/uncommited records (server/client)
              Arild

              When you update the related child records, you can choose not to use the replace field content, but rather loop through each child record and test the open state as you walk through the records. In you encounter a locked record, you can choose to show a dialog (simple) or to note the record Id in your session record or a change table record, noting the id, the field and the value you wish for this field to have (more work). Your FMserver or an On Timer script can then delay the change until the record no longer is locked. It will eventually be updated.

               

              In a small work group, I would suggest you let error capture off as you loop through the set of child records and let the FM error dialog tell you when the record is locked. Then you will know what account has the record locked and you can talk to that person.

               

              The only way to completely avoid record locking is to have ONE user perform these changes. That user can be the server performing all updates to all records. Set a one minute delay in that schedule and all records in the entire database will be updated ALWAYS without any lockings and the changes will never wait more than 1-59 seconds. Reather obvious when you think about it.

               

              Does this help or did I confuse you more?