Updating data
The following section pertains to Related Table Edit only. You cannot update data in Related Table Browse.
Saving Changes
When you issue the SAVE primary command, or the END primary command with AUTOSAVE set to ON, all changes to all tables are saved.
If you have the Auto Commit option set to ON, all changes to all tables are saved each time you press Enter.
When you issue the END primary command with AUTOSAVE set to OFF and Auto Commit set to OFF, the Edit End Confirmation window displays (Edit End Confirmation). The window displays for each table in which there are pending changes, starting with the last opened table. The window asks if you want to continue processing the END command. If you enter YES, all changes made to the specified table are cancelled. If you enter NO, you are placed back into edit for the specified table. To save your changes, use the SAVE primary command.
When you issue the CANCEL primary command, all uncommitted changes made to the active table and its dependent tables are cancelled.
If you enter =x in any related table window, the entire edit session ends and you return to the Edit Options screen.
Inserting Data
When you insert data in Related Table Edit, the foreign key field is prefilled and protected.
Related Table Edit
The foreign key in the employee table is the WORKDEPT column. When a new row is inserted, the WORKDEPT column is prefilled with the value A00 (see the following figure).
Inserting a Row — Foreign Key Prefilled
Deleting Data
If you delete a row from a parent table while in a Related Table Edit session, File-AID for Db2 adjusts the display for the dependent tables accordingly. If more than two tables are open, the deleted row in the parent table affects the display for all its dependent tables.
If your tables are related through an application relationship, the dependent table rows are only refetched; they are not deleted. If your tables are related through referential integrity, the delete rule defined through Db2 (cascade, restrict, or set null) is honored and Db2 may delete the dependent table rows.
If scrolling results in no rows in the dependent table relating to the parent table, an insert line displays. The foreign key field is filled with the primary key value from the parent table.
Deleting a Row in Related Table Edit
Deleting a Row in Related Table Edit shows a Related Table Edit session between the DEPT and PROJ tables. The relationship is based on the DEPTNO column in both tables. The D line command is issued to delete department A00 from the department table.
Display Adjusted After a Deleted Row
Display Adjusted After a Deleted Row shows the department table’s display reset to the next row, department B01. All the dependent rows in the project table’s display are fetched for the current parent row and refreshed. The project table’s display now shows all projects in department B01.
Changing Parent Record
When you change the related key column in a parent record while in Related Table Edit, the results differ for application relationships (AR) and Db2 RI relationships (RI).
Application Relationships
If a parent column of a relationship is updated, only that one row is updated. The corresponding key columns of the dependent table are not changed. After a successful update of the parent column in a Parent to Dependent REDIT session, the dependent table display is refreshed to show any existing dependents of the newly updated parent row. (Remember, in a Dependent to Parent REDIT session, the dependent table display is not refreshed as it behaves like an unrelated table edit session.) Whenever this type of change is made, the dependent rows become orphaned.
Db2 RI Relationships
A parent column of a relationship may only be updated if no dependent rows exist. Otherwise, Db2 returns a -531 SQL code when the update is attempted. This prevents orphaned rows in the dependent table. If an update of the parent column is successful, the dependent table display is refreshed to show that no dependent rows exist.
Related topics