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] **********************************************************************
