6 Replies Latest reply on Jul 23, 2017 9:27 AM by philmodjunk

    Container fields export




      I understand that the preferred/recommended way of migrating records from one database to another in an upgrade situation (i.e. I'm on V1 of the application but working on V2 and will want to move data from V1 to V2 when V2 is ready to go live) is to export the all records from each table and then import them into the new table in the new file.


      How does this work with container fields because when I "move all" in the table here, it moves InvoiceStore::Invoice but doesn't save it in the script. I'd do it by individual record and export a file but there's 15,000+ PDFs in this table alone and I'm just hoping there's a quicker way or the upgrade could take days!


      Script steps

      As selected from "move all"

      When I go back to specify export order InvoiceStore::Invoice is no longer selected.

      Table structure

        • 1. Re: Container fields export

          Are you making many changes to the invoice store table in the new database? If not you could export the invoice store as a new FileMaker database and then import it and re-link.


          You could also import from V1 to V2, select the invoice store table and let V2 create the new table. Then set up your relations.

          • 2. Re: Container fields export

            When moving data from v1 to v2 of the same file, exporting is not necessary. You can import the data directly from V1 into V2. I prefer to use a script for this that I have tested ahead of time on a back up copy.


            You may also want to research "data separation " to use a method that minimizes the need to import any data at all.

            1 of 1 people found this helpful
            • 3. Re: Container fields export

              sgljungholm - Thanks.


              I'm using InvoiceStore as an example. The application has about 35 tables and this is just one.


              The chances are that I am likely to modify all tables in the next version as I move things around to improve the way things are working.

              • 4. Re: Container fields export

                philmodjunk - thanks


                I'll look into data separation.


                I get the idea of moving from V1 to V2 you talk about but with 35 tables and, on average, 20 fields per table concerns me that one of the 700 fields is going to get overlooked and I was hoping there was an easier way.


                It strikes me as strange that as my container fields are stored externally, I can't just export/import the link/external location. Surely that's what the contents of the field actually are?

                • 5. Re: Container fields export

                  philmodjunk - I've just been looking at data separation. Looks like I might need a V1.5 as the way towards V2.


                  Presumably data separation impacts performance too?

                  • 6. Re: Container fields export

                    Data separation does not significantly impact performance in my experience. It does have "cons" as well as "pros" so research and test.


                    You have less less chance of leaving out a field by importing directly than by exporting then importing. When importing, you can select "matching names" to immediately align all fields that has the same name, you can then fix any fields that are new or renamed. The big thing though, is that you can use one script to do all of this--including the update of serial number settings, then test it on backups to be sure it is all correct before doing the actual update.