You may also want to offer just try doing 2c and use the get subrecord key function in v15. Keeping the id field.
________________________________ From: 4D_Tech <[email protected]> on behalf of Olivier Deschanels via 4D_Tech <[email protected]> Sent: Tuesday, June 11, 2019 11:34 AM To: 4D iNug Technical Cc: Olivier Deschanels Subject: Re: Replacing Obsolete Subtable Commands in v15 to v17 Migration 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: > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=02%7C01%7C%7C9a05eba12b9e49a20e6008d6ee60ba16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636958496540996996&sdata=Um7%2BO%2F2ri4rv9wgDVkyZ8YFBVHxVTkZ4Vqyam2PgCWo%3D&reserved=0 > Options: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=02%7C01%7C%7C9a05eba12b9e49a20e6008d6ee60ba16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636958496540996996&sdata=bcIYke2wiU4R2J9yBqd3rMbNpIYeG6aFtajetLvEuGw%3D&reserved=0 > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.4d.com%2Farchives.html&data=02%7C01%7C%7C9a05eba12b9e49a20e6008d6ee60ba16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636958496541007007&sdata=%2BMTQTbDD0PDR7pXXkxC1cxNefZrDT3oH4OiVfvCMcXg%3D&reserved=0 Options: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.4d.com%2Fmailman%2Foptions%2F4d_tech&data=02%7C01%7C%7C9a05eba12b9e49a20e6008d6ee60ba16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636958496541007007&sdata=hUwXL6EOPR0SRL3pkJwXaqXihae%2BTnY0g7hcP3uhcDY%3D&reserved=0 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] **********************************************************************
