Lee, I assume you mean migrate the data out of that structure and into a brand new one?
I'd say the thing to do is look at the result of opening it in v16 - which you already did and said the nested subtable isn't even there. So now add that table yourself linking as appropriate to the new table 4D created. The trick is going to be coercing 4D into exporting the second level subtable (and I just gotta say - what spectacularly bad idea that was) into some sort of data export. That's gonna be the key - whether you can even do that or not. But you said it's compiled. Does that mean you don't have the interpreted structure? If so I think that's the end of the story. Unless the guys at tech support can work some magic unavailable to mere mortals. Stuff like this makes me wonder what the real aim of this sort of perpetual backward compatibility really is. On Thu, Oct 12, 2017 at 6:07 PM, Lee Hinde via 4D_Tech <[email protected] > wrote: > In v16 the 2nd level subtable isn't moved over. The field is in the 1st > level subtable. My goal with all this is to write something to migrate the > data. > -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
