2 Replies Latest reply on Jan 14, 2010 6:34 PM by RickWhitelaw

    Merging files, scripts, tables, and layouts



      Merging files, scripts, tables, and layouts


      I have 2 files that I would like to merge and preserve scripts, tables, and layouts.  I don't want to have to rewrite a bunch of scripts and recreate a bunch of layouts.


      One is the filemaker email campaign starter solution. The second is the address book manipulator demo file (productivecomputing.com).  Both files have lots of scripts and layouts.  The two files both both manage contacts, but use different field names (company and company name for example).


      My desire is to utilize the filemaker email script along with the address book manipulator scripts and maintain interactivity with address book, but use the same contact data for both.


      The tough part is that filemaker::contacts and ABM::contacts need to be merged (preferably) or synced so that each script works, particularly the ABM sync with address book.


      I can copy all of the fields from one table to the other, but I can't reconcile the tables to the scripts and layouts.  Where there are two similar field names (company and company name), I would like to eliminate one in the 'merged' table so as to not repeat the field.


      When I merge one table, rename, and delete the old, I get lots of 'table missing' errors in the layouts and scripts.  


      Is there a way to 'trick' filemaker so that the scripts reference the merged table with renamed field names?





        • 1. Re: Merging files, scripts, tables, and layouts

          You can do it and there's even a utility offered that can make it easier. It's called FMMigrator. I haven't used it but would definitely check it out if I had another large number of tables to merge into one file.


          You can do it all in Filemaker, Filemaker Advanced is much better, but you have to do everything just so and sometimes do it twice to maintain the linkages. Some parts have to be recreated from a blank page by hand and must be recreated exactly like the original file.


          The best way to rename your table (or the table occurrences in the relationship graph), is to change its name in the original file first, then import it. That way all layouts and scripts that reference it can be imported with links that reference the new name.


          To merge files using just FMP:


          Compare files for matching table, table occurrence, script and layout names. WHere they match exactly, change a name in either file to remove the duplication.

          Use Import Records to import your tables.

          Print out the relationship graph in your source file (original file) for reference

          Open your target file and recreate all table occurrences and relationships that refer to the table just imported. You may want to establish external links to tables in your source file that you haven't yet imported and later point them at the new table created once you import it also.

          Open Manage value lists in the source file and copy custom value lists from the source file into identically named value lists in the target file.

          Recreate all non-custom value lists by hand in the target file to exactly match the ones in the source.

          Create blank layouts in your target file for each layout you want to bring over from the source file. Name them exactly like the original and point them at a table occurrence with exactly the same name.

          Copy and Paste all the layout objects from your source file into your target file's matching layouts.

          Import your scripts from the other file

          For every layout you've just pasted that has a button set to perform a script, delete the layout and re-copy and paste them from the original. You'll also have to create and size layout parts in your new layouts to match the originals. The object Info pallet can be used to size your layout parts to precisely match the originals.


          Now you have to test things exhaustively to make sure a typo or other error didn't break something. That's where a copy of advanced becomes handy because you can generate design reports and search them for keywords like "missing" and "unknown" to find such errors.


          You have to paste layouts twice to keep all the links working. The first time allows all the imported scripts to reference the right layouts. The second time enables all the buttons to connect to the right scripts.


          As you can see it's a lot of work, but it can be done, but a utility might make life a lot easier.



          • 2. Re: Merging files, scripts, tables, and layouts

            I agree with Phil's advice. However, you might want to consider if you really need to merge the files. Filemaker doesn't care if a table is in one file or another. Tables from multiple files can be used in the relationship graph. Your scripts would be maintained as well as the relationships you've established in each file already. You can add to the relationships in each file to achieve what you want and alter scripts as needed. It all depends whether there's an advantage to having a single-file solution, and you would know best. The solution I use most is composed of six files. One disadvantage, I'll admit, is complicated relationship graphs (and one per file) and a bit more work at establishing context, but some of the simpler files are actually easier to work with using this method.