1 of 1 people found this helpful
Yes, the problem is related to to the internal ID which is what FileMaker uses to keep track of field references. This is the reason we have the ability to change field names and all references update automatically, even if they are referenced in a separate file that might not even be accessible at that time.
But when you move a front-end file from connecting to a development data file to a production data file, FileMaker doesn't know it's a different file, so all the references are based on the internal ID's, which may now be different on the production data file.
The reason that COPIED scripts (and layout objects I think) work is because when you copy a script or layout object, the copied data contains the field names, not their internal ID's. When you paste, the scripts/objects are mapped back to the new record ID's based on name match.
Be careful, because not only could this cause "field missing" errors, it could also cause field references to get mapped incorrectly to other fields, which can really mess with your mind when you start reading your scripts and they make no sense! I'll leave it to someone else to describe best practices for avoiding this, as I don't have much experience with multi-file solutions myself.
Thank You , Jason !
I also found another discussion "Internal Field ID Problem?" which has very helpful information there as well.
I was hoping someone with more experience would have chimed in with some "best practice" advice on how to deal with this in a more regular/preventative way. Data separation seems to be popular but it's sort of based on the premise that modifications to interface are common, while modifications to fields/tables is rare. I've never attempted it - mainly for that reason.