4D v13.4Get subrecord key |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v13.4
Get subrecord key
Get subrecord key
The Get subrecord key command facilitates the migration of 4D code using converted subtables to standard code for working with tables. Reminder: Beginning with version 11 of 4D, subtables are not supported. When a older database is converted, any existing subtables are transformed into standard tables that are linked with the original tables by an automatic relation. The former subtable becomes the Many table and the original table is the One table. In the One table, the former subtable field is transformed into a special field of the "Subtable Relation" type and in the Many field, a special "Subtable Relation" type field is added named “id_added_by_converter”. This allows converted databases to function but we strongly recommend that you replace any subtable mechanisms in your converted databases by those used for standard tables. The first step in this process consists in deleting the special automatic relations, which permanently disables the mechanisms inherited from subtables. After this you need to rewrite the associated code. The Get subrecord key command accompanies this rewriting by returning the internal ID used by the relation. This internal ID makes the actual relation unnecessary and you can then work with the selection of the former subtable even when the relation is no longer present. Let's look for example at the following converted structure: In 4D v12, the following code still works but it must be updated: ALL SUBRECORDS([Employees]Children) You can now replace this code with: QUERY([Employees_Children];[Employees_Children]id_added_by_converter=Get subrecord key([Employees]Children)) Note: Get subrecord key returns 0 if there is no current recorded loaded when it is executed. The second piece of code has the advantage of using standard 4D commands and it works the same way whether the relation is present or not. When you remove the relation, the command simply returns the key value stored in the Longint field. In the idField parameter, the command accepts either a field of the Subtable Relation type (if the relation still exists) or of the Longint type (if the relation has been removed). In any other case, an error is generated. This lets you write the transition code. During the final stage of upgrading the application, you can remove the calls to this command. |
PROPERTIES
Product: 4D
INDEX HISTORY
Created: 4D v12.1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||