14 Replies Latest reply on Nov 9, 2015 7:17 AM by JonasGysin

    Advanced dev : Change object ID's in "Behind the scenes" fmxml ?


      Hi all,


      I have been trying to sort this out for a while now but can't figure out how.


      If you copy/paste a field/table or anything from FileMaker to Clip Manager 5 or event Text mate, you see the XML code of that object, containing the object ID.

      For example:


      <Field id="6" dataType="Number" fieldType="Normal" name="T40_product_number">


          <AutoEnter allowEditing="True" constant="False" furigana="False" lookup="False" calculation="False">



          <Validation message="False" maxLength="False" valuelist="False" calculation="False" alwaysValidateCalculation="False" type="OnlyDuringDataEntry">

            <NotEmpty value="False"/>

            <Unique value="True"/>

            <Existing value="False"/>

            <StrictValidation value="False"/>


          <Storage index="All" indexLanguage="French" global="False" maxRepetition="1"/>



      Only the first line is interesting here, you can see the <Field id="6"  witch FM uses to reference it's relations. If I just edit this number and copy the field back into FM, FileMaker changes the field id so this doesn't' work (even if I paste it in a new table, the FM will change the id to 1).

      How can I somehow override the defined ID?


      Here's what it's all about:


      In a multiple file database solution, I am working on a new version of a given database file (eg. Products_new.fmp12). This file is hosted on fmserver with all the other files.

      The fileds in tables of the original file (eg. Products.fmp12) are a data sources to the fields in other files (eg. Manufacturing.fmp12, Invoices.fmp12 etc.) There are quite many relations here so obviously, the goal is not having to recreate the relations manually when switching to the new file.

      How to do it? Filemaker "builds" it's relation based on the TableIDs and FieldIDs, not table and field names. So setting the new file to the same file name, table id's & field id's should do the trick.

      Now here's where trouble starts:

      What I did is that I went and looked at the ID's of the tables & fields in the old solution and edited the ID's of the new solution through copy/paste into Clip Manager 5 or TextMate, edited the Field ID, copied that to the clipboard, pasted it back into FileMaker (previously deleting the original field obviously).

      Here's the catch: FileMaker just changes the ID's to the next available number so if I had 100 fields in my table, my modified field will get the ID 101, no matter what ID I set before pasting it.


      Ps. I started from scratch instead of a copy of the original file because the original file is the kind of file that gives you nightmares...


      Thanks a lot to anybody who can help

        • 1. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

          The filemaker internal catalogs are not editable for a reason. Allowing any user the ability to edit a internal object ID would break filemaker unless you knew the source code inside FM.

          You have to figure out another way to accomplish your goals.

          2 of 2 people found this helpful
          • 2. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

            Hi coherentkris,


            Thanks for your response.


            I don't quite agree with your response. Editing the xml gives you the ability to change all the other parameters of for example a field. This is very useful in some cases. It's obvious that you need to know what you are doing, although I doubt making a mistake will "break" FileMaker. Probably just the db file itself. I get it that the ID is a parameter that's more delicate as for example the field type. However, I can't imagine that I'm the first person confronted with this situation, there must be some kind of workaround here... A tool or a plug-in that allows you editing this value perhaps?

            • 3. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

              You don't have to agree with the response but it is still true

              Yes: can edit the id in the XML, and yes, FM will just plain ignore it.


              The way to solve your underlying issue is to create an excel sheet with columns for the fields you need in their proper column to match their old IDs and dummy fields in the all the ID positions you don't need.  Then import that excel sheet with the option to create a new table.  That way FM will create the fields with the proper IDs.  You can then delete the dummy fields or leave them in for future re-use.


              Obviously  you only need to do this is maintaining the old underlying IDs is important (for instance: if you are going to replace just one file or table in a set of many).  If you are going to rebuild the whole solution from scratch then don't bother.

              1 of 1 people found this helpful
              • 4. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                There were tools around in the FM7 days that did this by reading the XML DDR.  FMrobot comes to mind.  It did a similar thing: create dummy fields to consume the "lost IDs" and then create the proper field in the proper sequence.

                2 of 2 people found this helpful
                • 5. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                  Sorry, Jonas. the recordID is unique to an object and as such cannot be changed.


                  Allowing changing of other values may be 'allowable' with this method, but not often 'advisable'. There are other ways to make these changes more safely.



                  • 6. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                    I've made pretty extensive use clipboard xml manipulation for a number of re-writes, similar to what you are describing, and also like to use it for other things.


                    Field ids aren't normally something I manipulate, and I do think that manipulating IDs exposes you to the risk that FileMaker internally resets the ids the way you or describing, at least if you haven't established a well tested procedure for what you are doing. However, I wouldn't consider the problem impossible to solve. You could probably do something ugly like paste all the fields at once, including dummy fields for the ids you don't want, save, check the relationship graph, and then go back and delete those dummy fields.

                    There are various methods for generating such dummy fields - I like to work with a FileMaker database and a table with records for each field, but you can of course do this with just scripting, xslt, or whatever you are most comfortable with.


                    Exactly how you would go about getting fields to have IDs that don't break IDs depends on what your whole workflow for this re-write is. I myself have so far always reset the relationships manually - while this is theoretically annoying, in practice, it has represented relatively little work to me compared to the rest of the work. So I haven't myself established an SOP for this, and I honestly don't see this as meaningful in most cases - if nothing else because the relationships are something I tend to want to redesign/optimize anyway when doing a re-write.


                    As for tools, I recall Bernhard Schulz of Schubec (Austria) demoing a tool at the German-language FileMaker conference a few years back, which might be getting close to what you're looking for - it did allow for editing the relationship graph. I'm not sure if he's completed this to a point where this has been released to the public. At least, this doesn't seem to be included in the latest version of the FM Code Library - I'm sure you can just ask him about this.


                    I haven't tried FM Pro Migrator in a while, but this could perhaps also be an option.


                    You can probably also do your own GUI-scripting to achieve something similar.


                    If you like clipboard fun, you should also have a look at fmWorkMake and other tools offered by Mr Watson.

                    1 of 1 people found this helpful
                    • 7. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                      Hi Wim,


                      Thanks for your ideas & thoughts.

                      I Thought about the dummy field trick, the thing is, (don't ask me how the original dev. managed that) some of the original ID's are very high, like between 195 and 263. Anyway, it's still the best trick I think.


                      What I'm not quite sure about, what about the table id? I am assuming that just giving the table the same name won't do the trick when I switch the files and try to get the other db's not to notice the source has changed (or at least, maintain all their relations).





                      • 8. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                        Table IDs don't matter in my experience.  FM never links directly to the table anyway.  You will have to double-check any Table Occurrences you have in other files.

                        • 9. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                          HI beverly,


                          Thanks to you too for your response. I'm not trying to change the record ID but the Field & table ID's of the database, not the data itself.
                          The reason why is that I have about 30+ fields in this file I am updating, that are used over 1'000x in various ways across the rest of the solution (in the other .fmp12 files)


                          You mentioned "There are other ways to make these changes more safely." Witch ones do you have in mind?


                          Kind regards,



                          • 10. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                            Hi Camel case,


                            Thanks to you also
                            Resetting the relationship's graph, layouts, scripts, calculations etc. would be hell to do, there are over one thousand places where that would need to be corrected.


                            But I'll check out the tools you mentioned, thanks.


                            ps. FMWorkMate's latest version is a beta released 20140716, do you happen to know if it works with fmpa14?

                            • 11. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                              You should ask Russell Watson directly, but to my knowledge it works fine with FM14 as well. fmWorkMate doesn't include much when it comes to layout objects, and that's the part where the FileMaker clipboard xml has changed the most between 13 and 14.

                              • 12. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                                sorry, any object "id" is internally set and as such is not modifiable. Wim gave you a good example of how to 'recreate' with the same id's and the use of dummy objects to keep the good ones in the correct order.



                                • 13. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                                  Jonas Gysin wrote:

                                  there are over one thousand places where that would need to be corrected.


                                  Invest in a tool like BaseElements from Goya... you can quickly build a list of external references that would need to be checked.

                                  • 14. Re: Advanced dev : Change object ID's in "Behind the scenes" fmxml ?

                                    Thanks to everyone who helped me address this issue and sorry for my delayed response.


                                    I figured out a way to do it a few weeks ago, thanks to different hints I found in this thread. I almost forgot to post back here but in the end, here's what I did/found out:


                                    The easiest and quickest way is in the end to create "dummy" fields.

                                    What I did is that I exported the table into clip manager 5, from there I exported the field names and ID's into an excel spreadsheet, imported this list into a quick filemaker solution with 2 fields: Name and ID. Quick script to create all the "dummy field" names and ID's, sort the list by ID (there were over 300 fields), exported that list to an excel spreadsheet.


                                    So now I had a spreadsheet with the first column containing the field names, the second the ID, sorted by field ID.

                                    Copy/paste all this into a new tab so that now the first line has the field names. You don't need the 2nd line once you're sure you've got the fields in the correct order.

                                    Then I imported that spreadsheet into a new solution, telling fm that the 1st line contains field names.

                                    (the whole things may look complicated but honestly it's quite quick and straight forward).


                                    Now regarding the Table ID's; there are table ID's! And it's the ID that keeps a table linked in a relation. The name of the table doesn't matter, same for fields.
                                    To keep it simple, get the table id's of the original file with this function:

                                    TableIDs ( Get ( FileName ) )

                                    then, cross reference that list with

                                    TableNames ( Get ( FileName ) )

                                    Afterwards it's just a question of creating n amount of "dummy tables" in the new file until the id's match with the old ones.


                                    So basically, once the filename, table id's and the field id's matched the old file, I could do what ever I had to do with my new "clean" solution, replace the original file on the server and voilà. All the relations etc that relied on this file stayed unharmed.


                                    It isn't quite what I imagined doing in the beginning but it's a workaround that turned out fine for me.

                                    If anyone finds a way someday to "edit" these ID's directly it would still be great and probably useful for a lot of people.


                                    Many thanks to coherentkris, wimdecorte, Beverly Voth and CamelCase201507 for your ideas, hints and support.


                                    Kind regards,