3 Replies Latest reply on Apr 10, 2012 9:17 AM by Stephen Huston

    How to deal with legacy container objects?


      We are considering the migration to FMA 12, but have a decade of files with container fields to deal with. For the most part, these fields have objects in them as most people tend to drag and drop files or images into them. What will FM 12 do with these objects? Ultimately, we would like to move them to an external folder with a web viewer to view them, but there are thousands of records in many files to contend with.


      D Valley

        • 1. Re: How to deal with legacy container objects?
          Stephen Huston

          I just converted an 69,000+ record file with fully-populated containers. FMP12 has them all, and they are stored internally by default.


          I will be  testing on changing the storage options after conversion, but haven't had time to get to that yet.


          As a start, the conversion for stored images worked perfectly and kept them stored internally.

          • 2. Re: How to deal with legacy container objects?
            Stephen Huston

            Edited 2:30pm


            I've now started converting that 11,000 69,000 image file from internal container storage to external storage.


            I set it to unsecured storage so I could watch the file-creation in the new directory structure as it exports to numbered.jpg images.


            FileMaker 12 first estimated disk space requried for creation of external storage, then started the conversion after confirming that I wanted to do this now. (It warned me it would take a while.)


            I told it to proceed, and, so far, it has done about 3300 records (one container/record) in the first 30 minutes. Some of the originals were PDFs of varying sizes, so, while this isn't the fastest thing I've ever seen in FileMaker,  for a one-time change as cleanup after conversion, it seems acceptable.

            • more new stuff:

            Checked on it at the 2 hour mark and 10%, roughly 7,000 records were complete. I realized at this point that this could take an entire 24 HOUR DAY on this particular file. It offered me a cancel or Stop button, so I clicked it.


            It told that space in the file for the exported images/files would be recovered when I closed the file, so I quit FileMaker. No problem so far... I thought!


            Then, when I then opened the file again, I got that wonderful error that permissions in the file had been tampered with and to contact FMI if recover didn't repair it. I had never actually gotten this error on any file I worked on ever before in decades of FM development, though I knew it was a reported error.


            Started recovery on this 9.8 GB file, but don't expect any happy endings. It's still in the works, and I expect it to be very slow.


            I will have to give some serious thought to when or if to change storage on an existing file this large. If  7,000 records in 2 hours is any quide, this file will take 20 HOURS to move a single container field to external storage, and who knows if the file will even work after that.


            More later,

            Stephen Huston

            • 3. Re: How to deal with legacy container objects?
              Stephen Huston

              Follow-up on the File Recovery started in my previous post:


              Recovery did run on this huge graphics file, but it took 2 hours and 20 minutes. At the end of the Recovery it reported the standard: Recover built a new database without detecting any problems. The new database is safe to use, though you should monitor the results carefully and make sure to keep up-to-date backups of your databases.


              I opened it with my Full Access account and got no error about tampered or damaged permissions! The permissions had been rebuilt during the final minute of the Recovery operation, and the log showed "No Access" to the details of accounts rebuilding, but it worked.


              This is a huge improvement for data recovery efforts if FMPA12 can actually get past that type of error. I still consider the recovered file unsafe, but am glad to see Recover performing better than earlier versions often did on that particular error.


              Tomorrow, time allowing, I will try my experiment of moving to external container storage with a file of more modest record count.


              Stephen Huston