from memory so... One note: - I believe existing (v15+) subtable support is one level deep only, I do not know if this will/does affect you. i.e [parent].substable_level1.subtable_level2... is not supported.
there is a special link between converted subtables and their parent. this special linage is NOT replaceable once broken. The special linkage allows the subtable commands to continue to function. (speaking about 1 subtable) I believe that if you remove the special link, and replace the subtable commands that use it with record level commands you are good to go. There may be one major exception: Reports using the subtable data. It has been along time since I played in this area, but again, as I recall any reports using the subtable commands will need extensive work. As subtable records load in a much different fashion to related tables. Depending on the subtable structure definition(s) you may also want/need to add a primary key for backup/journal purposes. On Tue, 11 Jun 2019 12:23:20 +0100, Narinder Chandi via 4D_Tech wrote: > Hi. So, after tackling the replacement of the majority of the > obsoleted commands in v15, the remaining ones are in the Subtable > commands group (ughhh!). The database I am upgrading has 11 > Subtables. I have spent some time perusing the archives prior to > writing this - a lot of the posts are quite historical, and there are > various options discussed in different threads. Having digesting > everything, these are the 2 options I am considering: > > 1. Do nothing - Subtables converted to regular tables in v11 and > currently working in v15 will continue to work as is in v17 using the > obsoleted commands. I view this option as just brushing the problem > under the carpet for another day and in the short term serves only to > save the client the expense of my consulting time. > > 2. Migrate all data access between Many to One tables to use Record > commands in place of the existing Subrecord commands. I envisage this > process would be something like: > a. Create a new Primary Key (PK) field in the One table (if needed) > and add that as a Foreign Key (FK) field in the related Many table > (see note * below). > b. Iterate over the One table records identifying the existing > related Many table records in the previously converted v11 Subtable > and update the FK field in each of the related records as required. > c. Convert all of the existing obsoleted Subrecords commands to > their Record command equivalents. > d. Break the relation between the "id_added_by_converter" field in > the Many table and the One table. > e. As the "id_added_by_converter" field in the Many table and the > Subtable field in the One table are no longer required they can be > now be removed? > f. Test, test and test again! > > Note that there may be other options to 2. above, but ideally I am > only looking to leave things as is for now or to completely solve > this issue once and for all. > > My question is - does option 2 stack up as an optimal and complete > solution? I think there is a less onerous solution that achieves the > same end goal based around using the "Get subrecord key" command but > I'm not convinced that I should consider that option. > > And finally, since I should give the client all acceptable > "solutions", is option 1 a viable option too? > > * since the v15 upgrade (I think) 4D Server has been complaining > about missing primary key fields in regards to the Log File so I need > to address the issue of missing keys in several tables in any case (I > have seen some prior discussion in the archives about this). > Personally I would never create a table without a (auto-incrementing) > PK but it's a legacy database that pre-dates my involvement... > > Regards, > > Narinder Chandi, > ToolBox Systems Ltd. > -- > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
