1 2 Previous Next 15 Replies Latest reply on Mar 30, 2016 4:20 PM by Vaughan

    Filemaker Conversion


      Hello All,

      Very soon I will be converting from FMS/P 11 to 14. Yea!!!!! My FM 11 database was converted from the FM7 Database which had been converted from the FM5.5 database. The end result is that I still have a multi file system on FMS 11 rather that a single file / multi-Table system.

      I do not want to simply convert the data files and end up the way I am now. I just built a custom version for one of my other programs and what I want to do is pull all the data in the old Multi file structure into a single file multi-table database.

      Once again I find myself turning to the wisdom of the discussion group on the best way to manage this.



        • 1. Re: Filemaker Conversion

          The attached document may be of some assistance. It's kinda old, but the advice for merging a multi-file solution is still very valid.





          • 2. Re: Filemaker Conversion

            Any Preference on Methodology Mike?

            • 3. Re: Filemaker Conversion

              My personal preference is a complete rebuild, possibly as a separated solution (depending on your needs). But that assumes you have the time and funding to do it.


              Eventually, you want to get there, but there’s nothing wrong with a phased approach. If that’s what you need, then I recommend just building a new interface file and combining data files over time. That’ll get you there as you have time.

              • 5. Re: Filemaker Conversion

                Thanks Mike...

                I actually have the rebuild 90% done because I had to create a version of my database for one of my other programs so since they will be starting from scratch they get the shiny new FMP 14 single file version. I will have to do a few tweaks to make it work at my primary site but nothing too major.


                My biggest concern was centered around the relationships and things breaking on the transfer I have a lot of related tables and I cannot afford to lose that related data

                • 6. Re: Filemaker Conversion

                  Yeah, that’s probably the ugliest part of a makeover like this. You have to go through the Graph very carefully to make sure you’re catching everything. TO names can be really important, too (since when you copy / paste scripts it’ll try to resolve based on the TO name).

                  • 7. Re: Filemaker Conversion

                    Remember to update the serial numbers in each and every table after the records are migrated!

                    • 8. Re: Filemaker Conversion

                      Can you explain that a little more Vaughan

                      • 9. Re: Filemaker Conversion

                        Certainly. The new database will likely have auto-entered serial numbers as primary keys. The "next number" needs to be updated after importing records so that it does generate duplicate numbers.



                        before import: table_1_id = 134

                        import 10,000 records, of which the last serial number is 12,254

                        need to change the next serial number to 12,255

                        • 10. Re: Filemaker Conversion

                          OK I get you. Thanks because I might have missed that in all the madness that I am sure will ensue...

                          • 11. Re: Filemaker Conversion

                            Updating serial numbers is very easy to forget. The tell-tale is users phoning up saying that new records are appearing with old related records in portals. It's possible to use unique validation on the serial number field to trap for this (it will fail very quickly) but the validation can slow down new record creation when record numbers get big.


                            One of the things I do with big projects is to script the process of migrating records from the old to new systems. Start early in the development cycle because it'll take weeks to get all the little details right, and try to do the migration at least once a week.


                            I usually script the process to clean up data (this can be accomplished by making calc fields in the old system and importing these instead of the original data) and import everything into the correct tables, reset serial numbers etc. Start early and keep chipping away at the process to automate as much as possible so that at the end of the project you can run the import scrips overnight and have new data to test with daily, and you are confident it will work.

                            • 12. Re: Filemaker Conversion

                              Thanks, That sounds like good sound advice. Will I need to create layouts in the old system that contain all the fields, or at least the ones I want to export, and the same for importing into the new system?

                              • 13. Re: Filemaker Conversion

                                Layouts display the current found set. Layouts can also have fields on them. Some operations like cut, copy, paste, and insert require the field to be on the current layout, but others like set field, export and import don't ned to have the fields on the current layout. I usually make a blank layout (no fields, no design, blank) for each table and perform a lot of functions like import and export from these layouts.

                                • 14. Re: Filemaker Conversion

                                  OK, I just wanted to add that to my to do list if I had to. I am assuming that I can make my life much easier is the calc fields in the old tables are the exact same as the fields in the new one.

                                  1 2 Previous Next