Ghost fields in Field Mapping when importing

[Daniel N]

I get these kinds of grayed out fields in "Field Mapping" in "Import Records" sometimes, what are those?

Direct link: http://img9.imageshack.us/img9/4281/ghostfields.jpg

[LaRetta]

Look at the location where your source would be (upper left in picture where pop-up shoudl be). You don't have one. I would suspect that you changed the source file name where the import was originally pointing.

Sometimes you can also get ghost 'fields' if the file exists and the prior import map was mapped to a field but later, you deleted the field from the source. It will remain attempting to map a deleted field on through. And there are other anomalies with imports as well.

Edited March 19, 2009 by Guest
Added paragraph

[Daniel N]

Look at the location where your source would be (upper left in picture where pop-up shoudl be). You don't have one. I would suspect that you changed the source file name where the import was originally pointing.

Sometimes you can also get ghost 'fields' if the file exists and the prior import map was mapped to a field but later, you deleted the field from the source. It will remain attempting to map a deleted field on through. And there are other anomalies with imports as well.

I actually want those "ghost" fields since import gives an error when it finds a file but can't import because of the "ghost" fields and another error when it doesn't find the file. Very useful in my scripts, so good to know how to replicate the bugg.

So, Thank you!

[LaRetta]

Ah, if importing were only that easy. You will always receive an FM error if the file can't be found but as for ghost fields, we're not that lucky.

1) If you are basing your import on last order (because the names do not match) and you are not importing all the fields from the source and if you then ADD a field to your target file, FileMaker will graciously map the next source field in line to your new target field and you will NOT get an error when it happens.

2) If your import based upon matching names and you change the name of one of your target fields, FileMaker will not import into that changed field and it will NOT produce an error.

3) If you are mapped upon matching names and the source file has many more fields (which you are not mapping in), you had better hope that you NEVER add a target field with the same name. Because if you do, it will map automatically and begin pulling that field into your target without producing an error so fields such as DateCreated, DateModified (if used in many files) can map unexpectedly.

4) If you are mapped on custom order and you delete a field in the target, FileMaker will simply map to the next target field in line and not produce an error.

A 'person' from FileMaker awhile back said that the answer to the random moving map lines was to always finish your FileMaker design and THEN make sure your maps were perfect and then not change anything. Oh dear ... that does NOT take into account that a solution is truly never finished; that here are always things being changed and expanded, fields being added/renamed, etc.

And the problem with an import which 'partially works' is, if it is ran automatically, you won't notice it didn't work right until your data is messed up. In a perfect world, we'd map on names alone but as Items 2 and 3 point out, it can still bite you if not careful.

Never trust FileMaker imports and never trust import error messages because you won't always get them when there is a problem. If any fields change in the source file (order of fields, field names), re-check your maps. And do the same with your target tables, re-check your maps. ALWAYS.