RDB/VMS Relational Database Operator CHANGE_RELATION — VMS CDD+_4.1A
Changes the definition of the fields that make up a relation. You can add, delete, or change fields in an existing relation. When you execute this statement, Rdb/VMS modifies the named field definition(s) within the relation definition. All the fields that you do not mention remain the same. Example: RDO> CHANGE RELATION EMPLOYEES. cont> DEFINE SALARY. cont> END EMPLOYEES RELATION. RDO> ! RDO> CHANGE RELATION DEPARTMENTS. cont> CHANGE DEPARTMENT_NAME cont> QUERY_NAME FOR DATATRIEVE IS "DEPT". cont> END DEPARTMENTS RELATION.
Additional information available:
More
When you execute this statement, Rdb/VMS modifies the named field definition(s) within the relation definition. All the fields that you do not mention remain the same. When you change a relation definition, other users see the revised definition only after they invoke the database the next time. You must execute this statement in a READ_WRITE transaction. If you issue this statement when there is no active transaction, Rdb/VMS starts a READ_WRITE transaction implicitly.
Format
CHANGE RELATION ──> name ───┐ ┌────────────────────────┘ └────┬─────────────────────────────────┬────> . ───┐ └─>
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) typebox (/)typebox (*) text */ ────┘ │ ┌──────────────────────────────────────────────────┘ └────┬──┬──>
D
E
F
I
N
E ──> change-clause ───┬─> . ─┬─┐ │ ├──>
C
H
A
N
G
E ──> change-clause ───┤ │ │ │ └──>
D
E
L
E
T
E ──> field-name ──────┘ │ │ └─────────────────────<─────────────────────┘ │ ┌──────────────────────────<───────────────────────┘ └────>
E
N
D ──┬──────────┬──> typebox (R)typebox (E)typebox (L)typebox (A)typebox (T)typebox (I)typebox (O)typebox (N) ───────> . └─> name ──┘
Additional information available:
DEFINE
Using the DEFINE option of CHANGE RELATION, you can add a globally defined field to a relation. You can also use a local field name to refer to that global field. change-clause = ──┬─────────>────────┬────┐ └──> typebox (/)typebox (*) text */ ───┘ │ ┌───────────<─────────────┘ └─┬──> global-field-name ─────────────────────>─────────────────┬─┐ └──> local-field-name ────┬─────────────────>───────────────┬─┘ │ └──>
B
A
S
E
D typebox (O)typebox (N) global-field-name ──┘ │ │ ┌──────────────────────────────────<──────────────────────────────┘ │ └───┬─────────>────────────┬─────────────> └─┬─> dtr-clause ────┬─┘ └───────<──────────┘
Additional information available:
Arguments
The action of CHANGE RELATION with DEFINE depends on the
change-clause, as follows:
o DEFINE field-name -- includes an existing global field definition
in the relation
o DEFINE field-name BASED ON global-field-name -- includes an
existing field definition in the relation, but gives it a local
name
o DEFINE field-name COMPUTED BY expression -- adds a new virtual
field
You can specify local DATATRIEVE support clauses on any of these
fields. For more information on the DATATRIEVE clauses, ask for
HELP on Field_attr.
CHANGE
The CHANGE RELATION statement with the CHANGE option modifies the local attributes of an existing field. Only the attributes you specify in the statement change; all others stay as they are. For more details, see the Arguments. change-clause = ──┬─────────>────────┬────┐ └──> typebox (/)typebox (*) text */ ───┘ │ ┌───────────<─────────────┘ └─┬──> global-field-name ─────────────────────>─────────────────┬─┐ └──> local-field-name ────┬─────────────────>───────────────┬─┘ │ └──>
B
A
S
E
D typebox (O)typebox (N) global-field-name ──┘ │ │ ┌──────────────────────────────────<──────────────────────────────┘ │ └───┬─────────>────────────┬─────────────> └─┬─> dtr-clause ────┬─┘ └───────<──────────┘
Additional information available:
Arguments
The action of the CHANGE RELATION statement with the CHANGE option
depends on the change-clause as follows:
o CHANGE field-name BASED ON global-field-name -- gives the
specified field the attributes of another field
o CHANGE field-name dtr-clause -- changes DATATRIEVE support
characteristics
You can specify local DATATRIEVE support clauses on any of these
fields. For more information on the DATATRIEVE clauses, ask for HELP
on Field_attr.
DELETE
Deletes the field from the relation. This option deletes the field only from the relation definition. The global field definition by this name is still defined for the database as a whole, and other relations can still refer to it. If an existing view, index, constraint, or computed field refers to the field, Rdb/VMS returns an error when you try to delete it. DELETE FIELD ───┬───> field-name ────┬───> . └────<──── , ────<───┘
Examples
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 name:
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.