5 Replies Latest reply on Jun 24, 2013 10:59 AM by BobGossom

    Records not comitting


      We're having problems with a database where the information in newly created records is being lost if the network/server connection is broken. I've checked the layout setup for the data entry layout being used and it is set to save record changes automatically. My understanding of this is that once you leave a field that you have entered data in that record is committed and the information is saved. However if I create a new record from that layout, enter data into five or six fields, then break my network connection, when I open the database again the record is there but all of the fields are blank - except the primary key.


      We're in FileMaker 11 Server Advanced running on a Mac Server. The data entry layout does use a custom menu in which I've removed the New Record, Delete Record, and Delete All menu items among others, but I can't think of anything there that would impact saving the records automatically.


      Is there some other control on the commit records that I am missing? Thanks in advance for any input.



        • 1. Re: Records not comitting

          "My understanding of this is that once you leave a field that you have entered data in that record is committed and the information is saved."


          This is not correct. Record commit is triggered by these events:


          1) Clicking on the layout outside of any field.

          2) Switching modes (going from Browse > Find, Browse > Layout, etc.)

          3) Changing records

          4) Opening the Manage Database dialog


          Just tabbing from one field to another will not cause a record commit. So the behavior you're describing is normal.



          • 2. Re: Records not comitting

            Mike is right.


            I'd also be worried about the matter of too many disconnections.

            Perhaps you should script the go-to-next-field with a commit in between fields. Or do an onexit script for the last field in the tab order.


            - Lyndsay

            • 3. Re: Records not comitting

              Lyndsay is right.   


              Frequent disconnects are worrisome, not only because you lose uncommitted changes, but because you risk corrupting the database, should a disconnect happen in the middle of, say, a record commit or large scale change. If you're seeing a lot of disconnects, it might be worth diagnosing your network situation and figuring out what's causing them.


              Oh, and I left out one other event that triggers a commit: Pressing the "Enter" key. Just to be complete.   



              • 4. Re: Records not comitting

                Thanks Mike and Lyndsay,

                I'm not sure how I missed that, and a little surprised it hasn't been noted by users before.  I think this may just be one or two users who, for some reason, have a habit of creating new records, entering some data and then walking away from their computer for awhile.  Perhaps I'll add a "Save" button - I don't really want to start adding script triggers to every field or anything like that.


                The network connection issue is something else that I'm working with their IT folks to try and resolve.  Not sure what I'll be able to do about that, at least not quickly.


                Thanks again,



                • 5. Re: Records not comitting



                  As mentioned in the thread, the only way to definitively deal with the situation you describe is with script triggers connected to the input fields. It's a pain to have triggers on every field, but it will work very well. There are at least two ways to do it:


                  1) Put a trigger on each field that commits the records after each edit. I think an "On Validate" trigger would be the way to go. This way if they "pass" through a field without entering/changing anything, it won't trigger a commit. You'll have to deal with the navigation (what field to go to next) within the trigger, as the commit will change the focus. There are many ways to do this, so post back if it gets dicey. If you are on a very slow connection, this might introduce noticable slowdowns with the multiple commits.


                  2) Install an "On-Timer" on the layout. This would commit the record after a specified period of inactivity. You'd need an Exit trigger on each input field that would "re-set" the timer. Each field would still have a trigger, but since exiting the field wouldn't commit the record - just re-set the timer variable - you wouldn't have to deal with the next field navigation issue mentioned above.