I have a script that performs a simple matching names, add new records import script step. The source is a hosted table on a FileMaker server. The target is a table hosted on a different FM server.

Whenever a field is deleted from the table in either the source or target (after the import step was setup), the field mapping ends up wrong when running the script. So the information is imported in, but in the wrong field(s). It's like it 'shifts' the fields down one space in the Import Field Mapping screen, for lack of a better description. The source/target tables get updated with new information/fields/etc on a fairly habitual basis so deleting a field on occasion is normal behavior.

I'm expecting that the import step will just ignore the field, rather than shifting all of the fields down/up one space. Since there are several developers on this particular system, finding out when a field is deleted may not be apparent right away to change/fix the import step.

I've done similar importing in the past without every seeing this kind of problem. Has anyone else noticed this behavior with FileMaker 11, and if it changed during a certain version change that I just didn't pay attention to?

That's why a somewhat common practice is to never delete fields.

Change it to an unstored calc field; and rename it something like zDeleted01. It retains its place in the creation order but match by name will ignore it and you cannot import into it.

Edited November 29, 201015 yr by Guest
change import order to creation order

Whenever a field is deleted...

Known dangerous bug.

See: http://forums.filemaker.com/posts/c2305cb3e0

Good to know that someone else is having this problem. Since FileMaker Inc is obviously aware of the problem, I'll just submit a report and stop complaining :