4 Replies Latest reply on Aug 9, 2010 1:53 PM by philmodjunk

    Database File Reverted to Older Version of Database

    MichaelKessler

      Summary

      Database File Reverted to Older Version of Database

      Product

      FileMaker Pro

      Version

      FMP 11 ADVANCED

      Operating system version

      Mac OS X 10.5

      Description of the issue

      I have been developing a database through the FMP network sharing feature.  For the past week I have been making changes to layouts, scripts, etc. and all changes were being seemingly saved as expected.  Whenever I reopened the file through the Remote connection changes made previously would appear. 

      I decided to move the file to a different disc so I closed the file from the Remote Host and moved to a new disc.  When I reopened the file, all of the changes I had been making were gone.  Nothing had committed to the actual file.  I have lost everything.   What happened?  Doesn't the sharing feature commit changes to the file or were they simply stored in cache and never really committed to the actual file.

      I had even copied the file (while it was still open and being shared) to make a back-up copy thinking the changes were being committed all along.

      One more kicker, the file was on a dropbox folder, however it was only being accessed by the host FMP and connected to through the sharing feature.

      Steps to reproduce the problem

      Haven't tried to reproduce...don't want to...I want my work back.


      But I guess they were:

      OPEN FILE
      TURN ON SHARING
      MAKE CHANGES OVER TIME
      CLOSE FILE
      MOVE FILE TO NEW DISC
      REOPEN

      Expected result

      Changes gone.  File reverted to version of file when opened.

      Exact text of any error message(s) that appear

      None

        • 1. Re: Database File Reverted to Older Version of Database
          TSGal

          Michael Kessler:

          Thank you for your post.

          Check your host machine for a file with the same name.  Also, check the Modification Date of the file to ensure it is the correct file that was copied.

          Also, open the file remotely, make one change and close it.  Open the file again to make sure your file was changed.  Go the host machine and check the timestamp when it was last modified, and make sure it is indeed the file that was updated.

          Please keep me updated with any progress.

          TSGal
          FileMaker, Inc.

          • 2. Re: Database File Reverted to Older Version of Database
            MichaelKessler

            Disregard the best answer.  Accidently tapped trying to post from my iPad.  FYI, the "Post Answer" text entry field would not allow me to input text from my iPad.  It simply tried to "select & copy" the field.  The keyboard would not appear as would be expected....but alas that is a different issue.

            As for my reverted database.  I had opened, made revision, closed, and reviewed to see if it updated soon after the problem occurred.  Yes.  worked as expected.  So it is still a mystery why a week of remote edits didn't ever once write to the actual file.  Does it store edits in a VM/cache for some reason? Is it a bug?  I can't imagine it is a fluke event.  I mean they were changes from over a week of revisions.  

            One thing I have though of, I closed from the window (i.e. the red X) and not the File menu Close command.   

            • 3. Re: Database File Reverted to Older Version of Database
              TSGal

              Michael Kessler:

              Closing the application will close the database file.  That would still write the information to the host file.

              Could the host have restored from a backup?

              Other than that, there is no reason why edits would work for a week and then revert to an older copy.

              TSGal
              FileMaker, Inc.

              • 4. Re: Database File Reverted to Older Version of Database
                philmodjunk

                This thread is another example of the value in keeping multiple sequential back ups. Sometimes a problem--which could be as simple as a data-entry error--goes undiscovered for some time. If you set up server to make nightly back ups and keep at least a month's worth, if not more, you can work back through the backups to find a file that can be use to restore lost/damaged data. Sometimes, just figuring out when the problem data changed is a major clue in determining how it happened so that you can make changes to prevent a repetition of the problem...

                In your case, if you could check each day's back up copy and then found an older copy with all or some of the missing design changes, you'd at least have avoiding losing all the changes and you may even have figured out how an older version was subsituted for the newer.

                That's assuming of course, that you didn't somehow open a copy on your local machine or from a different server...