Click above to get retro games delivered to your door ever month!

   The concepts previously described will be examioned by using an example.
   Let's consider the database described in the diagram:

   Let's consider the Invoice Header file which contains the CusCod field.

   Let's analyse what the operator, at the moment of inserting a new invoice,
   expects to be able to do.

   The user, after having inserted a number and a date for the invoice, is
   ready to insert data in the field Customer Code. At this point let's
   examine some of the cases that may occur:

     . The user enters the code "ISA" and expects to read "Italian
       Software Agency" in the field next to it (if previously entered this
       way).

     . The user does not remember any code and wishes to open a
       search window containing the customer codes available in the Customers
       file. When the code is confirmed, it will be copied into the
       decodification field.

     . The user inserts an inexistent code. The system tells the
       user that the code does not exist but, if desired, can be entered at
       the moment, without having to abandon the current working session.

   ...and many more situations can occur in which the above happens.

   In dBsee, the possibilities quoted above have been grouped under the
   concept of "Many to One" relation, also called "Lookup".

   Some details on the relation:

   Relation:               Many to One

   Parent                  InvHea (Invoice Header)

   Child                   Cus    (Customer)

   Index                   Cus1   (Expression: CusCod)

   Field                   InvHea->CusCod

   The file InvHea is related to the Cus file (Customers) on the field
   InvHea->CusCod. This means that more than one Invoice can have the same
   Customer for the header. It is also clear that a Customer can have more
   than one Invoice, but you don't need to define this relation since the
   data management criteria has already been established, if not for adding
   referential integrity functionality.

   We suggest, therefore, to closely evaluate how the data will be managed
   when setting the relation criteria. Relations that never get used should
   be avoided.

   The diagram shown below demonstrates how a N:1 relation is used to show
   information in a data entry frame.

   A.  A N:1 relation or lookup is needed to link, using a field
       (InvHea->CusCod), the InvHea file to the Cus file. In this case, it is
       possible to retrieve a complete description from the customer code.

   B.  A One to Many relation links the InvHea file to the InvRow file

   C.  A N:1 relation or Lookup links the InvRow file (ex. InvRow->MatCod) to
       the Mat file (Material File). In this case, it is possible to retrieve
       and display a more accurate and comprehensive description of the
       material from the material code.

   D.  The InvRow file contains the InvNum field (invoice number). This field
       is not displayed, since 1) it contains the same code for each row and
       2) it is already displayed in the upper part of the screen.