Hello, Another option is to think object. ie replace a sub table by an object field ... including a collection (that’s not the only design).
Regards Olivier Envoyé de mon iPhone > Le 11 juin 2019 à 13:23, Narinder Chandi via 4D_Tech <[email protected]> a > écrit : > > 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] > ********************************************************************** ********************************************************************** 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] **********************************************************************
