AnsweredAssumed Answered

change table for instance yet match fields?

Question asked by njem on Sep 28, 2013
Latest reply on Sep 30, 2013 by Mike_Mitchell

I have two tables that should have been combined all along. I can fix that if I can get this straight.


I can import all data from tbl1 into tbl2. I can make sure all the field names names match between the two (before the import). Then I could find each instance of tbl1 and tell it to instead switch to sourcing from tbl2. That way a complex set of instances and relationships and such doesn't need to be disrupted. It almost works but layouts that show fields from one of these changed instances gets the fields mixed up. I can see that there is some relationship to field order. If tbl1 had Name in position 4 and tbl2 has Address in position 4 then a display field that should be Name shows Address instead. I tried just manually moving field order around to match but it didn't help. (That is, went to a backup before any of these changes, moved the fields first, imported, then change the source table for the instance.)


I suspect under the hood FM is keeping its own table of what field numbers go with what fields. That's probably how it can keep track of, for instance, chaning the name of a field in the data half of a data-separation set up and yet fields in the UI half don't get confused by that. FM is tracking the fields by some Field ID# under the hood or something.


But once they're given that number on creation then moving them around in order doesn't change it. Is this what FM is doing? Is there a way to see FM's own table under the hood? Is there a way to change the source table for an instance and have it find the right fields from the new source?