Procedures for Creating Relations

In order to set up relations between records you must first create a new record in refine masks, aggregate masks, type masks or link masks. Then you select the desired child record in the displayed master fields of the child entity, enter possible relation attributes and finally save that. There are three different methods to select the child record. These methods use DataView standard functionality or are the result of automatic definitions when default relations or type masks are generated.

Basically, all three operations are insert operations. Thus, the functional sequence -> write new records into the database is triggered. Additionally, the following procedures are automatically installed at default refine/aggregate and type masks. They become effective with all methods mentioned above. If required, you can modify the procedures in application-specific masks or you can apply the procedures to link masks.

Checking Selected Child Elements for Existence
DataView automatically installs the standard field userexit cch_get_rec at the Post-Field trigger of the displayed (significant) master attribute field. After a new entry in the field the userexit checks whether a corresponding child entity exists at all. If this is the case, all master attribute fields additionally displayed in the relation mask are automatically filled. If a corresponding child entity is missing, no relation can be created.

In the same way you can use the corresponding standard field userexit cch_get_cns in link masks. After a new entry it will for instance search whether an element with the same name exists in table 1 for a 1:1- or 1:n link from table 1 to table 2 at a displayed master attribute field of table 1 (valid for display of linked data in one single list, confer -> Representation of linked data in masks).

Controlling Field Access
The -> field access is automatically and mode-specifically set for the displayed (significant) master attribute field (A = *). For Insert mode it is set to write (I = w) and for Update mode to read (U = r). This allows the user to enter/select the significant attribute of the child record and create the relation, but he cannot create a relation to a different child record if the updates a relation record later. The defined field access automatically also applies to any installed modal window. In case of Reid privileges it cannot be opened.

In link masks you can set the field access for the displayed master attribute of Table 1 in the same way. If a modal window is installed at the field, the access to it must be explicitly controlled. This is done via the mode-specific access setting for the invisible key field 2 (the entries in this field are changed when a link is established). If, for instance, you set U = r there, the modal window cannot be opened in Update mode.


Exchanging Child Elements in Update Mode

As shown above, field access allows selection of child records for creating relations in insert mode only. In Update mode users can only change relation attributes. If you also want to allow selection or exchange of child elements in Update mode, you will have to change the automatically set field access for the significant master attribute fields in Update mode from read to write (U = w). Please note that exchanging child elements in the relation table results in a change of C_ID 2. To be exact, an old relation is deleted and a new one is created. For application-specific reactions on this special procedure any userexit at the Pre_ or Post_Action trigger will not be passed the standard parameter pr1=U but pr1=X in the -> standard functional sequence Edit.

Using the default variable REPLACEMODE you can generally allow or prohibit the exchange of child elements in Update mode in your application (ON = allowed, OFF = prohibited).


Record Locking While Creating Relations

You can control the locking of parent and child record when relations are created with the help of the default variable RELATIONLOCK. The default setting is ON and means that access to parent and child record is locked for other users while the current user is creating the relation. If you switch the automatic locking off, several users can use parent and child record at the same time. So it may be possible that two users simultaneously enter parts into a unit list. You have to accept, however, that because there is no locking a child record can be deleted until the relation record has been saved. If any user deletes the child before the current user has saved the relation, the latter will receive a corresponding message when he tries to save it.