AnsweredAssumed Answered

Scripted Import Oddity: A Bug?

Question asked by ralvy on Jul 28, 2010
Latest reply on Jul 30, 2010 by ralvy


Scripted Import Oddity: A Bug?


I have an import script that imports data from a copy of an existing database into a newer version of that database. I notice that if I add a table to the newer version, and add the appropriate import steps to the import script to handle that table, there's an oddity that can occur if the older source file doesn't have that new table. Just to be clear, when I set up this scripted import step, I make sure I have a copy of the newer file as the source, so I can see the correct mapping is handled by Matching Names.

Then I copy an older version into the appropriate folder to see what the script step will look like. Again, the older file doesn't have the new table. In such a case, when I look inside that import step in the script, FM will pick some table in the source file (not sure how it picks it). It's obviously not going to be the newer table, since it doesn't exist in the source file at this time. This isn't  a problem if none of the fields in the incorrect table match fields in the target table in the newer file, because I have Matching Names governing this process. But if FM finds a matching field name in the source table, it looks like it will use it and trigger an import. At least it looks that way when I examine the script import step (I see the import arrow telling me the field will import, even though the tables don't match).

For now, I renamed the field FM sees as a match so this won't happen. Is there a more elegant way around this? Or can I assume the import won't happen when the tables don't match the tables of the configuration that was there when this script step was saved, even if the field names match?

Am I being clear here?