4 Replies Latest reply on Aug 11, 2010 9:37 AM by TSGal

    Script Import Picks Wrong Table



      Script Import Picks Wrong Table


      FileMaker Pro


      11 v2

      Operating system version

      XP SP3

      Description of the issue

      I posted this here today:

      If a script import step references a table that doesn't exist in the source file, the import step might still show a field will import if Matching Names is active and FM finds a table with a field that has the same name as that found in the target table.

      Steps to reproduce the problem

      1. Add a table to your solution that has a field name that matches a field name in all the other tables.

      2. Place a copy of the new solution in a separate folder.

      3. Create a script step that imports data from the new table in the file copy (in the other folder), to the same new table in the original, using Matching Names.

      4. Now replace the copy in the other folder with the older solution (the doesn't have the new table).

      5. Load the script and see what FM says that new script step will import.

      Expected result

      You shouldn't see a table picked in the source side of the dialog, or if you do, none of the fields should import. This is because the source file doesn't have the table the script step was setup to import from.

      Actual result

      FM displays some table to participate in the import (obviously not the one chosen when the script step was set up). And if FM sees a matching field name, it will say it will do the import because Matching Names is active.


      I made sure I altered the field name in question, in the target table, so Matching Names fails to find a match.

        • 1. Re: Script Import Picks Wrong Table
          Steve Wright

          Whilst not quite the same, my solution has undergone some hefty structural changes over the years.

          What I have always done is during any scripted import process, first import a single record / field from a table containing the version number of the file, then based on this information let the script decide which tables it should process etc.

          Although it seems complicated, its fairly straight forward to maintain.

          If I added a new table, I would simply wrap the import step like below

          If [GetAsNumber($data_version) > 2]
             Import Step here
          End If []

          Since my clients may upgrade at various stages, this approach worked best for me.

          • 2. Re: Script Import Picks Wrong Table

            I've thought about doing something like this. Unfortunately, my data file doesn't contain a version number field. It should. My UI file does. I'll have to consider this more seriously now.

            • 3. Re: Script Import Picks Wrong Table


              I'm pretty sure that, when the table defined in the script step as the source table doesn't exist (because the source is an older version of the solution), FM incorrectly picks the first table created in that file as the source.

              • 4. Re: Script Import Picks Wrong Table


                Thank you for your post.

                I am able to replicate the problem on Mac OS X 10.5.8, Mac OS X 10.6.4 and Windows XP.

                One field from the original table must exist in the first table of the file for this to occur.  Otherwise, you will receive the correct error message that the table/fields cannot be found.

                I have forwarded your post along with my findings to our Development and Software Quality Assurance (Testing) departments for review and confirmation.  Until this is changed, use the workaround provided by SWS (Thank you!).

                FileMaker, Inc.