1 Reply Latest reply on May 9, 2014 6:47 AM by Mike_Mitchell

    Splitting a database - Creating a clone and importing/transferring records

    justtivi

      As a way of archiving and sharing disconnected data, I'm trying to create a script to, in essence, export a set of records away from the main file onto a scripted creation of a clone.


      After creating a clone, I'm lost on how to migrate a current found set and related records to the new file, as variables don't transfer over. A script trigger on the clone can't pick up variables created from the original file.

       

      A script-trigger on the clone to import records from the current found set that is open on the original file seems to work for one table, but when I create a second script step to import records from a related table, I can't specify a different table without a dialog window. I'm trying to map out the imports without any perform dialogue windows.

       

       

      Hoping to find a way to do this all natively.

       

      Is there a file-to-new-file way of doing this, carrying information to a new file?

       

      My last resort option it seems to me might be some crazy utility table where I copy everything on the original file, then allow an automatic import script trigger on the new clone to import the utility table data and loop through to create new records and parse out the data throughout every table. There must be an easier way.

        • 1. Re: Splitting a database - Creating a clone and importing/transferring records
          Mike_Mitchell

          Couple of different approaches:

           

          1) The quick-and-dirty way would be to do an export (to FileMaker files) of the table data you want (parent table and all related tables). Use predictable file names, then script the imports in the clone. You can delete the temporary files by doing an export of an empty record set when you're done to the same file name.

           

          2) A more sophisticated, but more complex method, would involve the use of an intermediary file that has the clone on its Relationships Graph. Again, you'll have to use a predictable file name, but you could deploy the helper file to the same directory from a container field in the original database using Export Field Contents. Then, you can run a script in the helper file that grabs the records in the parent file from a return delimited list of key IDs that you pass as a parameter from the parent file. Since the related records should all have the same parent key values, you can grab as many related tables from the same list as you need. (The reason for using a helper file rather than doing it directly from the parent file is that any file on the Relationships Graph will be opened when the file is opened. If the clone doesn't exist, you'll be pestered with the "I can't find it" dialog, which will be annoying.)

           

          HTH

           

          Mike