Example 1

    The following example adds an existing field definition to a
    relation:

    CHANGE RELATION EMPLOYEES.
         DEFINE SALARY.
    END EMPLOYEES RELATION.

    This example simply names an existing global field, whose
    definition becomes part of the definition for the relation.

    Example 2

    The BASED ON clause adds a local field name to a relation:

    CHANGE RELATION EMPLOYEES.
         DEFINE CURRENT_SALARY BASED ON SALARY.
    END EMPLOYEES RELATION.

    This statement performs the same function as in the previous
    example, but uses the BASED ON clause to give a local name to the
    field. The statement assumes that SALARY is defined globally in
    the database.

    Example 3

    You can change the local attributes for a field definition
    inside the CHANGE RELATION statement without changing the global
    attributes of the field for other relations that refer to it. The
    DATATRIEVE support clauses defined locally override those defined
    globally.

    CHANGE RELATION DEPARTMENTS.
        CHANGE DEPARTMENT_NAME
            QUERY_NAME FOR DATATRIEVE IS "DEPT".
    END DEPARTMENTS RELATION.

    This statement changes QUERY_NAME for the DEPARTMENT_NAME
    field, but only for the DEPARTMENTS relation. The definition
    of DEPARTMENT_NAME remains the same for any other relations that
    use it.

    Example 4

    You can change a local field so that it is based on a different
    global field without changing the the name of the local field:

    DEFINE FIELD SALARY
       DATATYPE SIGNED LONGWORD SCALE -2
       VALID IF SALARY > 8000
       MISSING_VALUE IS 0
       EDIT_STRING FOR DATATRIEVE "$$$$$$9.99".

    DEFINE FIELD MONEY
       DATATYPE TEXT SIZE 8
       VALID IF SALARY > 8000
       MISSING_VALUE IS 0
       EDIT_STRING FOR DATATRIEVE "$$$$$$9.99".

    CHANGE RELATION EMPLOYEES.
      DEFINE SALARY.
    END.
    CHANGE RELATION EMPLOYEES.
      CHANGE SALARY BASED ON MONEY.
    END.

    This example assumes two fields, SALARY and MONEY, defined
    globally. They have different data types.

    o  The first CHANGE RELATION statement adds a field to EMPLOYEES
       using the global SALARY field definition

    o  The second CHANGE RELATION statement uses the BASED ON clause
       to substitute the MONEY definition for the global SALARY. The
       local name remains the same, but that name now points to a
       different global definition. There are now two fields named
       SALARY in the database, one local and one global.

    Example 5

    A COMPUTED BY field is calculated from another field in the
    relation:

    CHANGE RELATION SALARY_HISTORY.
       DEFINE SS_DEDUCTION
         COMPUTED BY (SALARY_AMOUNT * 0.0625).
    END SALARY_HISTORY RELATION.

    This statement adds a "virtual" field, whose value is computed
    from other fields.

    Example 6

    The following example deletes a field:

    CHANGE RELATION COLLEGES.
        DELETE CONTACT_NAME.
    END COLLEGES RELATION.

    This example changes the COLLEGES relation by removing the
    CONTACT_NAME field from it. A global field is still defined for
    the database as a whole, and other relations can still refer to
    it. It may have some other name, if CONTACT_NAME were defined
    with the BASED ON qualifier. This statement also makes the data
    associated with that field invisible.

    Example 7

    This example changes the field-level primary key constraint for
    the field DEPT_CODE to a field-level unique constraint.

    RDO> CHANGE RELATION JOB_HISTORY
    cont> DELETE CONSTRAINT JOB_HISTORY_FOREIGN3.
    cont> END.
    RDO> CHANGE RELATION DEPARTMENTS
    cont> DELETE CONSTRAINT DEPARTMENTS_PRIMARY1
    cont> CONSTRAINT DEPARTMENTS_UNIQUE UNIQUE DEPARTMENT_CODE.
    cont> END.

    The example illustrates how constraints can refer to each other.
    Before the primary key constraint DEPARTMENTS_PRIMARY1 can be
    deleted, you must delete the foreign key constraint JOB_HISTORY_
    FOREIGN3.

    Example 8

    The following example shows that objects in the database with a
    dependency on the EMPLOYEES relation must be deleted before the
    EMPLOYEES relation can be deleted:

    RDO> START_TRANSACTION READ_WRITE
    RDO> CHANGE RELATION JOB_HISTORY
    cont>    DELETE CONSTRAINT JOB_HISTORY_FOREIGN1.
    cont> END.
    RDO> CHANGE RELATION SALARY_HISTORY
    cont>    DELETE CONSTRAINT SALARY_HISTORY_FOREIGN1.
    cont> END.
    RDO> CHANGE RELATION DEGREES
    cont>    DELETE CONSTRAINT DEGREES_FOREIGN1.
    cont> END.
    RDO> CHANGE RELATION RESUMES
    cont>   DELETE CONSTRAINT RESUMES_FOREIGN1.
    cont> END.
    RDO> CHANGE RELATION RESUMES
    cont>    DELETE CONSTRAINT RESUMES_UNIQUE_EMPLOYEE_ID.
    cont> END.
    RDO> DELETE TRIGGER EMPLOYEE_ID_CASCADE_DELETE, STATUS_CODE_CASCADE_UPDATE.
    RDO> DELETE VIEW CURRENT_INFO, CURRENT_SALARY, CURRENT_JOB.
    RDO>
    RDO> DELETE RELATION EMPLOYEES.
    RDO> ROLLBACK