Links

You create a link in order to connect data elements in database tables via key fields. The internal Ident number mechanism installed in DataView tables is not used by the link. Compared to relations, a link uses additional possibilities:

A link itself requires no mapping in the form of a database table. However, this advantage is only effective with 1:1 and 1:n links. n:m links require a 1:n and a n:1 link to be created using an auxiliary entity and the connected database table ( -> multilevel links). Adequately to the relation table this would contain the relation attributes. As opposed to the relation this auxiliary entity can also be mapped as foreign format table in the database. This auxiliary table will then have to contain two key fields in order to combine the two 1:n links to the n:m link. That is why n:m relations are better realized with the DataView relation.

Each link your create originates at a table 1 and is directed to a table 2. Just as with relations, several links can originate from or be directed to one table.


Key Fields for Links

It is a precondition for the creation of links that at least one key field exists in the set of object-specific attribute fields in both tables to be linked.

Key fields are fields whose attribute entries allow records to be unambiguously identified. Consequently they can be used to create links. Basically, each field on a database table - with the exception of internal system fields and multilingual fields - can be used as key field. In practical work, however, it will usually be number fields that unambiguously define records (as e.g. an item number). Usually you find a suitable key field only in one of both tables. If, for instance, you want to create the 1:1 or 1:n link between the master table of items and the master table if the stores entity in the meditronic application, you will also have to create the Number key field selected in table 1 in table 2 in order to be able to realize the link. The key fields in both tables must have the same type and length.

It is useful to index fields which you want to use as key fields, make sure that the index is unambiguous and - especially for foreign format tables - that the key fields do not contain any empty entries. You can specify this setting for each table field in the fields Index 1-3, U (Uniqueness 1-3) and N (Non-Zero flag) of the Table Fields list. If you compose a combined key of several fields, you must specify the same index for all fields involved.


Display of Linked Data in Masks

Data of linked tables in masks of the user interface can be displayed without any limitations. There is no function for creating default masks. You have to manually create link masks in the lists of the mask management. You will usually extend copies of default masks of included model objects by attributes of the linked table. But you also select a mask display which displays dependent elements of a link similar to refine- or aggregate lists of a DataView relation.

If you want to display for instance a 1:1 or a 1:n link in a mask, you can extend the default mask of table 2 by attributes of table 1. The link mask will then display the master attributes from table 2 and the selected attributes from table 1. Make sure that the mask contains the key fields of both tables. Because these fields show similar attributes, you can make one key field invisible in the mask. It is useful to make the key field of table 2 invisible, so that you can use the procedures for creating new links (selection of elements from table 1 in the modal window) at the visible key field of table 1.

For 1:n links you can create link masks which, analogous to the refine- and aggregate masks of a DataView relation for a selected record, shows all linked records from table 2 from within the default mask of table 1. For this you can use the default mask of table 2. The key field contained should be made invisible, because it would show the same key field attribute of the calling record for all records displayed.

Example: In the meditronic application the Item master table is linked to the storage master table. All items are stored in a storage. This storage has storage positions. Each storage position can only hold one item, but each item can be stored at several storage positions. All storage positions are managed in the storage entity. Each storage position is uniquely identified by a storage position number. A storage area is an additional storage attribute. In order to realize the 1:n link between the entities Item and Storage a key field has to be found. Without any doubt this is the item number field. In the Item master table (table 1) it uniquely describes the item records. In order to create a link to the storage position, the storage master table must also contain this key field. For each storage position will only hold one item (1:1 relation), the storage master table (table 2) can be extended by a similar number field without any problems. The linked data can be displayed using modified master masks. The figure shows two variants:


Controlling the Representation by Outer Joins

The representation of data in link masks can be influenced by two outer join flags.

>Outer Join
At a query request this form is an outer join for links directed from table 1 to table 2 (TABLE1 WHERE TABLE2.KEY = TABLE1.KEY(+)).

<Outer Join
At a query request this form is an outer join for links directed from table 2 to table 1 (TABLE2 WHERE TABLE1.KEY = TABLE2.KEY(+)).

Attention! The join setting influences the representation of data in all link masks (i.e. masks containing key fields from tables 1 and 2).

Example: In the Meditronic sample application the material master table (table 1) is linked to the storage master table (table 2). The representation is done in a storage master list extended by material attributes. Without >outer join this list can only display storage spaces already occupied by materials; with >outer join also unused storage spaces can be displayed.

Where condition without >outer join for table 1:
MED_ARTIKEL WHERE MED_LAGER.NUM=MED_ARTIKEL.NUM
The storage list only displays occupied storage spaces.

Where condition with >outer join for table 1:
MED_ARTIKEL WHERE MED_LAGER.NUM=MED_ARTIKEL.NUM(+)
The storage list displays all storage spaces; even if they are not occupied.


Information about Multilevel Links

Basically, DataView only supports single-level links. Links incorporating more than two tables in the form table 1 -> table 2 -> table 3, like they are for instance required to create an n:m relation, can be created in DataView on modelling level, but do not work on the second level. If you want to display the fields of the incorporated tables in one mask, the explicit specification of a- > mask join from table 2 to table 3 is required.


Information about BLOB/Longtext Fields in Link Masks

If a form contains a BLOB field or a mask contains a Longtext field from a linked table, it will only be correctly filled if the link has been created as follows. It is a precondition that all participating tables are tables in the DataView format.

Single-level link table 1 -> table 2, BLOB/longtext field is in table 2
If the tables are linked via the DataView model object Link, the contents of the BLOB/longtext field will be correctly displayed. If the link has been realised by a mask join, the C_ID from table 2 will be missing in the mask. However, it is required to display the BLOB/longtext field contents. For this reason you should explicitly create a field with the name C_ID and the Integer type in table 2 and assign the field to the mask.

Multilevel link table 1 -> table 3, BLOB/longtext field is in table 3
Because the link does not work on the second level and has to be realised by a mask join, the C_ID from table 3 will be missing in the mask. Create a C_ID field in table 3 as described above and assign it to the mask.

How to Create a Link (1st Method):

  1. Open the Link Data form and enter a new link record.

    Field Comment Confer
    Link name Here you enter the link name. -
    Title The object title is used in error messages and is required for selecting the main entity in the dynamic query mask.
    Tables-1
    Table-2
    Here you enter the names of the tables to be linked or select the tables from the menu (tables are sorted for model objects). -
    >Outer-Join
    <Outer-Join
    With the help of outer joins you influence the representation of data in link masks. -> Outer Joins
    > Ch (Check value)
    < Ch (Check value)
    Here you set the number of dependent child records up to which parent records can still be deleted. If possible use the default setting offered. -> Check for dependent elements
    > (Delete Flag)
    < (Delete Flag)
    Here you set whether child records are also to be deleted when parent records are deleted. If possible use the default setting offered. -> Automatically deleting dependent elements
    Key-1
    Key-2
    Here you enter the key fields from table 1 or 2 or select them in the menu. The menu automatically offers fields from the selected tables only. You can subsequently select several key fields (combined key), << CLEAR >> deletes any key field entry already entered. -> Key fields for links

    After saving the link has been completely created. You neither have to create a database table nor default masks.

How to Create a Link (2nd Method):

  1. Open the form for creating the model object which the link is to originate from, i.e. the Entity Data form, the Entity Type form or the Relation Data form (the latter one is only possible via the Entity Data form) and get the desired model object into the header form.

  2. Change into Link-1 sub-list (for 1:n link) or into the Link-2 sub-list (for n:1 link) and enter a new link record.

  3. Specify all field entries in the same way like for the 1st method. The name of table 1 is automatically assigned and depends on the model object selected in the header form.

    After saving the link has been completely created. You neither have to create a database table nor default masks.