14 Replies Latest reply on Jan 22, 2010 2:43 PM by philmodjunk

    My users report loosing ALL data entry when server bumps them off.

    PaulBostwick

      Title

      My users report loosing ALL data entry when server bumps them off.

      Post

      My users report loosing ALL data entry work on a layout if the server bumps them off. Not just the field they were in but all the work on the last record they looked at and updated.  Environment is FMP as client FMP server as host...

       

      is this as expected? I thought each field's data was sent to the server as you tabbed out or otherwise exited a field? if this is not the case how can I gracefully impose a more frequent flush cache to disk (assuming that works as I thought)

       

      Thanks in advance.

       

      -paul

        • 1. Re: My users report loosing ALL data entry when server bumps them off.
          philmodjunk
             It sounds like the record was not yet comitted. Have you changed the settings for the layout so that records aren't saved automatically? That could be the cause.
          • 2. Re: My users report loosing ALL data entry when server bumps them off.
            PaulBostwick
              

            Thanks for replying...

             

            I'll double check (I inherited the database and there are MANY MANY layouts) so I'll take a look around.... (goes to check the layout the user was on...)

             

            nope it has the check box checked for "Save Record Changes Automatically"

             

            did my understanding, namey that each field is written to disk as you exit it, match yours?

            • 3. Re: My users report loosing ALL data entry when server bumps them off.
              MikeyG79
                 What about memory settings in FMS for cache and time for clearing it?
              • 4. Re: My users report loosing ALL data entry when server bumps them off.
                philmodjunk
                   I could be wrong here, but I don't see how the cache settings on the server would be a factor here as long as the record was comitted.
                • 5. Re: My users report loosing ALL data entry when server bumps them off.
                  PaulBostwick
                     I'll look at the server settings too... but I thought it would just catch the stuff from the clients as soon as the clients got around to sending it. Right now it looks like the client is holding a batch of changes to multiple fields before sending them "home" to the server.
                  • 6. Re: My users report loosing ALL data entry when server bumps them off.
                    philmodjunk
                       In layout setup... for a given layout there's a check box: Save Record Changes Automatically. If that box is cleared then clicking on a blank part of the layout does not commit (save) the record. Have you checked that possibility out yet?
                    • 7. Re: My users report loosing ALL data entry when server bumps them off.
                      PaulBostwick
                        

                      Sorry I was not clear: I did look at it and it was checked.  :^( 

                       

                      arg.

                       

                      it is an old and hoary copy of a copy of a copy so it could be damaged i suppose. I can imagine a scenario where the "automatically update" is checked but that check is not seen due to damage. 

                       

                      I'll try to run a recover just in case. 

                       

                      Is there anything else I should look at when I go in under the hood next?

                      • 8. Re: My users report loosing ALL data entry when server bumps them off.
                        philmodjunk
                          

                        Hmm, I re-read your first post. If the user tabs from field to field, I believe the record stays open and the changes are not committed. If the user clicks even one time on a blank part of the screen, the edits are saved (committed). You might add a "save" button that doesn't actually do anything to your layout. (Since clicking it is the same as clicking the layout background and this will commit the record.)

                         

                        You could play with the Install On Timer script step (filemaker 10 only) and set up a script that saves the name of the current field, commits the record, and then returns the cursor to the saved field name. It's a pain to set up as you have to name all your layout objects in the layout (If I'm remembering correctly), but it should work.

                         

                        A simpler trick might be just to set up a script trigger on several key fields that commit the current record whenever the user presses tab, return or enter.

                        • 9. Re: My users report loosing ALL data entry when server bumps them off.
                          davidanders
                            

                          <Paul Bostwick

                          it is an old and hoary copy of a copy of a copy so it could be damaged i suppose. I can imagine a scenario where the "automatically update" is checked but that check is not seen due to damage.

                          I'll try to run a recover just in case.

                          Is there anything else I should look at when I go in under the hood next?>

                           

                          Not having a known good backup of a database is a bad practice.

                          Trying a recover of a database that is exhibiting corruption symptoms can be frustrating.

                          I would

                          1] Close Filemaker that is hosting the file.

                            [1A] May help prevent further corruption

                          2] Copy the database with the OS (preferred) (copy will be renamed) or Save As Copy with Filemaker (difficult if FileMaker is closed in step one)

                            [2A] Can help lessen fragmentation

                            [2B] Can point out hard drive failure - if copy causes error messages

                          3] Open the OS copied version in Filemaker

                            [3A] Can help prevent final corruption of orginal database

                          4] Save As Clone (empty) in Filemaker (this may cause global fields to be reset to blank, depending on FMP ver)

                            [4A] With large databases, can drastically shorten the diagnostic time.

                          5] Recover (under Filemaker File Menu) the clone (this will rename the cloned recovered database)

                            [5A] Actually attempt the repair

                          6] Open the copied, cloned, recovered database and test

                            [6A] May require importing data from the Database Copy to do useful tests.

                           

                           

                           

                           

                          • 10. Re: My users report loosing ALL data entry when server bumps them off.
                            FentonJones
                              

                            I was reading about this in another discussion, and worried a little about it. Then I realized that the setup on the client I was thinking about had more or less solved this problem, without even trying to; at least I think so.

                             

                            We are saving backups every hour. The Server drop time limit is 1 1/4 hours. I believe the 1st thing the backup routine does is write the cache to disk. So effectively no one could be kicked off with data in the cache.

                             

                            The only real downside is that the backups slow things down for a short while. 

                            • 11. Re: My users report loosing ALL data entry when server bumps them off.
                              PaulBostwick
                                

                              1) David... That is a good recipie for a cleanse. The copy with the OS is an interesting step as is the recover a clone rather than a data filled version.

                               

                              It is backed up pretty seriously but the backups are only as good as the source up so I'll take the prescription to heart and use it to "firm up" the current version while I do an overdue fresh ground-up rebuild.

                               

                              2)  Phil... I have pretty cooperative users and telling them to occasionally click outside the fields will probably get some useful action. I say cooperative - but they still will not tell me what the dialog or monolog boxes tell them when these awful things happen... AAARG!

                               

                              Ok off to record a user tutorial that includes "tapping the background for good luck" There are about 35 layouts and each has 100 or so fields so monkeying with even a fraction of the fields would be a bummer. especially in a system I want to spin-down soon. Maybe i can change the background to a color to help identify it as a place to  touch to send an update to the server...

                               

                              Do i have that right? The act of leaving the field - where the record is still selected but there is no active field - this initiates a flush of the cache from the client to the server?

                               

                               3) Fenton... I think you are talking about the server crashing. I am dealing with the client dropping its connection with data from multiple fields on the same record not yet pushed to the server... I think that is different but related. No?

                               

                              Thanks for the help all!

                               

                              I'm leaving this one open, in case there is some second thought that comes through.

                               

                              • 12. Re: My users report loosing ALL data entry when server bumps them off.
                                TSGal

                                Paul Bostwick:

                                 

                                Thank you for your posts.

                                 

                                Two things immediately come to mind.  One of our in-house database files has some fields that need validation, so when the person attempts to commit the record, it must go through validation.  There have been times when I left in the middle of entry, only to come back later and realize I was bumped, so none of my changes were committed.

                                 

                                The other thing is another file is set up similarly, but there is a red button in the bottom right corner which prominently displays "Save Record".  Although it probably does the same action as clicking outside the field, users are definitely aware it is there, and most users click it.  I guess it is more of a psychological factor than anything else.

                                 

                                TSGal

                                FileMaker, Inc. 

                                • 13. Re: My users report loosing ALL data entry when server bumps them off.
                                  PaulBostwick
                                    

                                  So it sounds like writes up to the sever happen not between tabs but between exits of records. So the more fields on a layout the stronger the chances for losses in the event of a connection failure or a bump out for no action costing you data. Fair enough...

                                   

                                  I'll add a red save button here and there.... green? something lovely.

                                   

                                  Thanks all!

                                  • 14. Re: My users report loosing ALL data entry when server bumps them off.
                                    philmodjunk
                                       If you have a very large amount of fields, you might split them up over two or three data entry layouts with a "continue" button to take them to the next layout to finish the data entry. Just switching layouts will probably commit the record and if not, the button's script can include that step.