I'm not sure I follow this description. What do you mean by "user code"?
Do you have two files to your solution and user interface front end and a data back end?
Is this an update of the back end file or the front end?
Are your screen shots from the front end or back?
The solution has 2 files D1 - the database (back end) and U1 the front end. The database runs on a Mac OSX server (running Filemaker Pro 10 (non server version)) and the clients are running Filemaker Pro 10 and Filemaker Pro 10 Advanced.
The update incorporates layout, script and relationship changes in U1 and table updates (new fields) in D1.
The screen shot is a script from the front end (U1).
I tried deleting the fields in D1 and adding them again to see if the problem would go away, but it has not.
I can't seem to replicate this problem using filemaker 11 on windows xp and I wouldn't expect either the difference in OS or filemaker versions to make a difference here.
What I did:
- Created a File Back1 with three text fields: Field1, Field2, Field3 in a table called Data.
- Created a file Front1 with no fields and added a table occurrence to "Data" from the Back1 file.
- Created a simple script with three Set field steps assigning a number to each of the three fields in Data.
- Saved a copy of both Back1 and Front1, naming the copies Back2 and Front2.
- Opened Back2 and added two new fields: Field 3 (global) and Field 4 (non global)
- I then opened Front2 and edited the reference to Back1.f71 to be Back2.fp7.
- The fields still correctly mapped to fields 1, 2 and 3 in the script in Front2.
I may not have correctly replicated what you have done. See any differences?
Your setup correctly follows the setup I'm using. The difference in the steps is:
step 5 - added Field 3 and Field 4 to Back2
step 5b - updated sample script from step 3 to assign values to Field 3 and field 4
I've applied maintenance to both the backend and front many times over the past year. While the majority of the updates are only related to the front end, as this series of updates involved deleting records, all development was done against a copy of the backend, verses the production version.
I have 2 development environments (sites) for this solution, and often move the back end and front end between sites and then move either into production.
In this case, once the development was complete, the updates were applied to the production backend. It was only today that I tried to access the backend with the new front end.
When I open the script shown in the screenshot, I can update the fields to the correct names as the fieldnames are found in the script editor - even though they show up as unknown initially.
I also have a large solution with a separate development set of files. There is more than one developer involved. Sometimes an immediate fix/update is applied to both copies of a particular file (after properly closing the production files via its FileMaker Server). We are using "separation of data", with an "interface" file (also on the server).
FileMaker uses the hidden Field ID of a field for mapping, not the name. If a field is created then deleted in one of the files, but is never created in the corresponding table in the other copy, then subsequent fields in that table will not line up. Because the Field IDs have been incremented in one and not the other.
What I've done is create a layout, with only 1 field on it. I change both the underlying table occurrence and the field, depending on what table/field I need to check. I put the last field, in creation order, from the relevant table, onto the layout. I then run a simple script step via a button, to produce a dialog. The contents of the dialog are field name and its ID. The functions are FieldIDs and FieldNames, both in the Design functions. Since there's only 1 field, I get its name and ID. I compare the IDs between the 2 systems BEFORE creating a field in both (well, usually, and sometimes otherwise wish I had).
If the IDs are off, the only way to fix it is to create a field, then delete it, from the table where the ID is too low. Or import all the data, from all tables, into the one with the correct IDs (PITA).
I have exported all the data from the production database and imported it into a clone of the development database as suggested by Fenton Jones and with this I'm able to migrate the developments into production.
Thanks for the recommendation.
Yes, that is a way to bring the data into a separate development, but different from what we were discussing. Over time you may use both methods (quick fix vs. update entire file).
It is extremely important that all "serial ID" fields be updated properly to the "next serial number" of the existing production files, after/during import routines into a clone. There are a couple ways to do this, with pros and cons. But it must be done or all relationships using them will get all mixed up, new vs. old data.