3 Replies Latest reply on Sep 10, 2014 9:27 AM by TSGal

    Damaged file on server

    ryyno10

      Title

      Damaged file on server

      Your post

      Yesterday one of our FM11 files crashed (I know, we haven't upgraded for reasons out of the scope of this question.  We are, however, running the most recent version of FM11).  I checked the event log and discovered the Event 618: "Database or temporary file "File_Name" is damaged and has been closed. (824)".  I also tracked down some other server events that occured during this time: Event ID 900, 902, 1003, and 1066.

      I restored the most recent back-up file into production and haven't encountered any problems since.  I was able to recover the damaged file and pull data from each table that was updated during the time between most recent back up and crash (about an hour worth of production).

      The back-up file, which is currently in production, has passed the consistency check, however, I'm worried that some type of insiduous corruption might exisit within the file.  Should I be concerned?  Also, I'm working on a re-design, we will soon be using a different database program for some of our workflow processes.

      Should I rebuild the file from scratch and import my data back into the new file?  Any comment would be greatly appreciated.

        • 1. Re: Damaged file on server
          TSGal

          RYYNO10:

          Thank you for your post.

          If you haven't run into any corruption with the back-up file, then continue to use it.  Be sure to also keep frequent backups for the near term.

          You may also want to run a Recover on the backup file to ensure no errors are reported.  Although 99+% of the time, it's fine to use a Recovered file, consider rebuilding the file, creating each table and layout from scratch.  Once finished, import all data from the backup file, remove the backup file, and place the newly rebuilt file into production.

          TSGal
          FileMaker, Inc.

          • 2. Re: Damaged file on server
            ryyno10

            Thanks for the info TSGal.  I did some digging around and found an old back up from 2010 and it successfully past recovery.  Would you stil recommend re-building from scratch?  Unfortunately, this seems to be something that was overlooked for quite some time during by the previous developer and plenty of functionality was added to this DB...  I'm rushing right now to rebuild in fear of the file crashing again so I may re-build the best back up, get that into production (after testing) and then start rebuilding from scratch.

            • 3. Re: Damaged file on server
              TSGal

              RYNNO10:

              It looks like the immediate concern is to get the solution running quickly.  Therefore, do what you have to do to get the data to the clients.

              As mentioned before, continue to keep frequent backups until you have a long term solution.  You may or may not have to rebuild the file from scratch, but keep notes of any crashes that occurs from this time forward.  Specifically, what was the client doing before the crash, what layout was being accessed, what table was being accessed, what script (if any) was being performed, etc.  This may help narrow down any problem areas.  Sometimes, a layout is damaged, and by creating a new layout and deleting the damaged layout may be all that it takes.

              TSGal
              FileMaker, Inc.