AnsweredAssumed Answered

Imports are worthless and dangerous

Question asked by LaRetta_1 on Apr 10, 2010
Latest reply on Apr 14, 2010 by TSGal

Summary

Imports are worthless and dangerous

Description of the issue

The spontaneous field mapping in imports still exists.  It has been reported several times in several forums. FMI acknowledges it, refuses to say when or if it will be fixed ... simply turns a blind eye.  Here is an example: http://fmforums.com/forum/showtopic.php?tid/209592/fromsearch/1/hl/import/tp/1/ So maybe another simple example of the extreme danger is required to get the attention of FMI: Example:  You have a Customers table with pk_customer_ID and an Actions table with fk_customer_ID.  As a developer, you want to import a found set of customer IDs into your actions table to create a specific action (such as sending a mailing).  Sounds perfect for an Import script step ... after all, how dangerous could it be when you are simply importing ONE FIELD? The answer is VERY dangerous ... Because the field names don't match (pk_customer_ID and fk_customer_ID), the process will break and data will be overwritten.  All that needs to happen to cause disaster is to add a new field in your target (Actions) table.  Here is another example (I have a test file attached to the link above as well): Customers table has 6 fields:pk_customer_IDnameaddresscitystatezip Actions table has 4 fields:pk_notes_IDfk_customer_IDActionDateDescription Your import only maps the two keys together; how simple, huh?  Now 6 months down the road you decide to add a field in Actions called ActionType.  It doesn't matter if it is a global field (to be used for an important script process) or a data field for users to type information ... the data in that new field is important that it remain for the use you specify, right?  But it won't. What happens next time you import?  Two fields from customer will suddenly import into Actions... your pk_customer_ID to fk_customer_ID AND the 5th field in customers (state) will map spontaneously to your new Type field.  You won't be warned nor asked.  FMI admits it breaks - it has since vs. 7.  But they will NOT even warn people by putting a note of caution in their FM Help and there isn't ONE WORD about it in Knowledge Base!!!  And when you run an import only once a year, and Users have entered Important information in a new field for that year, and you then run your yearly import which UPDATES fields, you now have lost a lot of critical data.  And you may not notice it for quite some time.  How many years will it take for FMI to provide an alternative, a warning, a way to identify spontaneous imports when they occur, or at least post its dangers?  We are now going on 6 years and 5 versions!! It will always break if you are not importing on matching names (most imports are NOT matching on names) and if the source table has more fields than the target and you add a field to the target table.  This happens with all source data, regardless of whether excel, tab, fp7 etc. Simply ... don't use imports.  They are not safe.  FMI, are you reading this?  Do you care at all?  It seems you don't.  There are things you can do to protect us and instead you stick your heads in the sand and ignore the issue.  You should be ashamed and all you customers and developers should be furious about it.

Outcomes