7 Replies Latest reply on Jul 11, 2010 9:58 AM by FentonJones

    Field Mapping problems moving development to production

    smcfeeters

      Title

      Field Mapping problems moving development to production

      Post

      My development database has a series of upgrades I want to migrate into production.  One of the updates has added 3 fields to a table, call them F1, F2 and F3.  These are all global fields.  There are script and layout changes to incorporate these fields and all are working fine in development.  The setup has the user code in database U1 and the data is database D1.

      When I add the fields to the production database (D1) and point the user code (U1) to use this database, the fields F1, F2 and F3 get jumbled.  F3 - appears as <field missing> on the layouts, and F1 and F2 are reversed in their initialization script.  If I switch the U1 to point back to the Development version of D1 - everything is fine again.

      The development version of D1 was a copy of the production version 4 weeks ago.  It is almost as though the creation order of the fields is what is being used, rather than the names.... any ideas who to get these upgrades installed successfully?

      ScriptChange.png

        • 1. Re: Field Mapping problems moving development to production
          philmodjunk

          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?

          If so....

          Is this an update of the back end file or the front end?

          Are your screen shots from the front end or back?

          • 2. Re: Field Mapping problems moving development to production
            smcfeeters

            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.

            • 3. Re: Field Mapping problems moving development to production
              philmodjunk

              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:

              1. Created a File Back1 with three text fields: Field1, Field2, Field3 in a table called Data.
              2. Created a file Front1 with no fields and added a table occurrence to "Data" from the Back1 file.
              3. Created a simple script with three Set field steps assigning a number to each of the three fields in Data.
              4. Saved a copy of both Back1 and Front1, naming the copies Back2 and Front2.
              5. Opened Back2 and added two new fields: Field 3 (global) and Field 4 (non global)
              6. I then opened Front2 and edited the reference to Back1.f71 to be Back2.fp7.
              7. 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?

              • 4. Re: Field Mapping problems moving development to production
                smcfeeters

                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.

                • 5. Re: Field Mapping problems moving development to production
                  FentonJones

                  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).

                  • 6. Re: Field Mapping problems moving development to production
                    smcfeeters

                    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.

                    • 7. Re: Field Mapping problems moving development to production
                      FentonJones

                      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.