I have a shrinkwrap solution with a separate installer/updater file. That file contains the scripts that creates a temporary file of each of the old and the new FMP file, performs an import into the new file then compares the results and continues. When I prepare the installer, I need to have a copy of each of the old and new FMP files so the updater file can map the fields that are used in the temp files. The purpose of the structure is so I don't have to remap the fields or check the field mapping each time I do an update.

 

Someone else has written this for me and I've generally still only used FMP 11. I understand that FMP 13 maintains field mapping by the field ID rather than the field name. Also, this seems very familiar and I'm pretty sure someone has written and sells something like this - I can't remember who though.

 

There's an assumption that all the tables exist and fields will only be added and not deleted to new files over time. The files have an internal BuildID that's used to track revisions.

 

The person who wrote this for me has said I don't need to be concerned with the version of the 'old' file and to simply always provide the first version of the solution. The field mapping will always be correct.

 

I can't think of a specific situation when this won't work, but it doesn't seem to make sense. I feel like I'm just not thinking clearly and missing something but I would think that a specific old version of the file would have to be provided. It seems that I would need a separate script (or some sort of branching) for each 'old' build of the file to assure the mapping is correct.

 

Does anyone have any thoughts as to what could go wrong here? I do a variety of validation after the export but since admin privs are removed from all the files it's very difficult to check everything for a possible field mapping error.

 

Thanks much!

I use RefreshFM, which sounds like it works very similar to what you are describing.

 

Since you never delete fields, it may work without having to specify an old version. The best way to find out is to test it, though. Do you ever rename fields? I would imagine that wouldn't cause an issue, it's just something else to consider.

Thanks Dan,

 

I think it is RefreshFM that I saw. It looked good and in retrospect it may have been easier for me to get and modify it.

 

At some point, field names will likely need to be changed. I think that's not supposed to be an issue since FMP now uses the Field ID for import field mapping. I guess that change takes care of my problems. It just seems too simple now

 

Thanks again.

 

FMP now uses the Field ID for import field mapping

 

I was unaware of this.

 

How is field mapping by matching names supposed work in that case?

In the interface, you'll still use field names but under the hood, FMP matches the field IDs so if a name is changed, the mapping is retained.