Hi Chuck, In answer to your several questions:
> ...When I open the structure, I still see subtables there. I also see the > tables that have been created as part of conversion. What gives? The new > tables appear to be there. I believe 4D deprecated subtables starting with v11. When converting from a pre-v11 version with subtables, 4D automatically creates a regular table in place of each subtable. When creating the new regular table to replace the subtable, 4D's naming convention is “<parent_tabel_name>_<subfield name>”. Note the underscore character, separating the names of the parent table and subtable field. All data from the original subtable is now located in the new regular table. > I am not sure what to do now. Complete the subtable conversion by replacing all obsolete subtable commands. The value in the parent’s subtable field “History Detail" and converted subtable field “id_added_by_converter” are the same. That’s a unique Longint value that relates parent to its subtable data. Beware — you need to use the command “Get subrecord key” to access the parent’s subtable field’s value. I’m talking about the field "[Contract]History Detail”. That field is now a Longint, even though the structure editor shows “Subtable”. It’s value is how you will locate the “subrecords" which are now records in a regular table. Subtable behavior will continue, as long as you don’t make any structure modifications to the original subtable field (in the parent table) and the “id_added_by_converter” field (in subtable that’s been converted to a regular table.) You should replace all subtable commands (which are obsolete) and replace them with “regular” table commands. I believe the command “Get subrecord key” will help navigate the relations until you complete the switch from subtable commands to regular table commands. See: http://doc.4d.com/4Dv17/4D/17/Get-subrecord-key.301-3730628.en.html > > For example I have a table named > Contract with a subtable named History Detail > > I also have a table named Contract_History Detail which has field named > id_added_by_converter. The original subtable field “History Detail” is in the parent table “Contract”. That field’s type should appear as “Subtable”. Use the command “Get subrecord key” to access (or view) the “History Detail” field’s value, which is a longint. All the subfield’s data has been moved to the new “Contract_History Detail” table. That’s the table with the field “id_added_by_converter”. The subfield “History Detail” and the field “id_added_by_converter” in the new table “Contract_History Detail” form the relation between the data in the parent table (Contract) and the subtable’s data (Contract_History Detail). > Can I just change type. why would I still be seeing this subtable the id > points back to the field in the Contract table No, changing the field type will end the automatic subtable behavior. Wait until you complete the subtable conversion by replacing the obsolete subtable commands. Then decide how you would like to relate the records. The subtable id that points back to the field in the Contract table preserves the relation between the parent record (Contract) and its subtable now located in a regular table (Contract_History Detail). They contain the same Longint value. At the moment, the data value that binds the subtable records to the parent table is: the parent’s subtable field (“History Detail”) and the “id_added_by_converter” field in the new regular table “Contract_History Detail”. Both are Longints. See: http://doc.4d.com/4Dv17/4D/17/Subrecords.201-3729374.en.html Does this info help? - Jeremy French ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
