Maps break (again)

[LaRetta]

Well, I posted this last night and, if you view Forums, it shows my post. But the post is no longer there. So I'll try again ...

I have spent hours and hours mapping a migration in Import scripts (many fields from many files). The fields are not in same order nor are they same names. I have matched arrows on hundreds of them. Then, we deleted some fields in the source files and all my maps break - every one of them - the arrows no longer line up to the right fields; they have jumped many fields off.

It seems that joining two fields in the import map (in scripts) does NOT hold. This is ridiculous. Once you click the arrow between fields, they should stay JOINED and not move, even if you delete fields from either file. I can understand the other fields moving but NOT the ones mapped with arrows!! Does anyone have suggestions? Also, I wanted to warn everyone because it will cause you great grief.

LaRetta

[Genx]

... yeh, I can't believe how much FM still sucks at importing things.

My suggestion is never delete fields, wipe their contents and rename them to something generic like "spare_field" and use them when you need to add a new one, but NEVER delete if you want your import scripts to work as you set them up.

Doubt that helps, but I gladly contribute to your rant.

[LaRetta]

I've handled many migrations and importing (using vs. 6 and 7) and I do not believe this has always been the case. It used to work - I swear!! I doubt very much, with all the mapping and migrations I've done that I have never deleted a source field during any of those times. And I am sure I would have noticed this before.

Rant is right ... FM sucks at import/export mapping (in general). It is obvious that they have never had to drag those darned fields up and down and attempt to map them. The interface is a disgrace. I wanted to delete many of the source fields which are NOT being migrated so my import mapping would be easier but nada ...

People - NEVER EVER delete fields in either files when you have ANYWHERE an import/export map in script maker. It will probably break it (although I haven't tested all possibilities). But it is DANGEROUS behavior!

Thanks anyway, Alex. :wink2:

[Genx]

You're probably right in general - but have never really trusted the import field mapping system - i did once and it bit me in the a%%.

This is one of the really key things I hate about FM at the moment epecially after having used SQL for a few months - The cool thing about SQL is you can reconstruct schema and easily swap data around without annoying and tedious dialogs - argh FM, thats all I have to say to you at the moment- ARGH!!

Anyway, I'd also be grateful if anyone has any rules of thumb about when the mapping will and won't break.

Edited September 18, 2007 by Guest

[Ender]

Greetings folks,

I've handled many migrations and importing (using vs. 6 and 7) and I do not believe this has always been the case.

I'm afraid this has been the case for a while. Import matching is done by relative creation order. If you delete a field, it shifts those fields created later up in the import order.

I too have lamented over this behavior (especially after it's bit me). Unfortunately, I don't see a very good alternative. If matching were done by name, then a simple change of a field name might screw up the import order (then we'll really see you complaining). If you've got a better idea, let's hear it!

Another similar problem (that's harder to troubleshoot) is that the import order can shift if the account doesn't have permission to view a field (I haven't tested this in FM9 yet). Imagine the ways this one can cause mischief!

[LaRetta]

I am simply at a loss for words.

Two tables, same file (one the source and one the target). If you have a scripted import from source to target and 5 fields are mapped (with arrow) but three aren't (and source and target field names do not match). And if you then delete a field in the Source table (and NOT one that is mapped with arrow), it breaks all the mapped fields - they shift. You don't even get a warning or error or hint that your entire script has become worthless - worse ... it's become dangerously wrong!

FileMaker doesn't even notice that the Source table is within itself!!?? Even the field definitions, even Set Field[] script-steps ... they ALL NOTICE if something changes within the same file!! Even layout names change properly!! But not import mapping?

Imports - Exports can no longer ever be trusted. Deleting fields in tables/files ... changing field names in tables/files - this is all normal behavior.

I am dumbfounded at FileMaker.