Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

More

Format

Examples

field-attributes

data-type

dtr-clause

missing-value-clause

Format

RDB/VMS Relational Database Operator CHANGE_FIELD — VMS CDD+_4.1A

 Changes an existing global field definition.  When you use the CHANGE
 FIELD statement to change the attributes of a global field, Rdb/VMS
 changes only the attributes you mention in the statement.  All other
 attributes remain the same.

 Example:

 RDO>  CHANGE FIELD POSTAL_CODE
 cont>    DATATYPE IS TEXT SIZE IS 9 CHARACTERS.

 The CHANGE FIELD statement changes the field definition:

  o  In all the relations that refer to that field
  o  In the data dictionary (if you use INVOKE with the PATHNAME
     qualifier)
  o  In the Rdb/VMS system relations

Additional information available:

MoreFormatExamples

More

 When you use CHANGE FIELD, you should be aware of the following
 conditions:

  o  If you change the data type of a field that is mentioned in an
     index definition, Rdb/VMS returns an error message and does not
     change the field.  To change the data type of a key field, you
     must first delete the index, then change the field, and finally
     redefine the index.

  o  You cannot add or change a VALID IF clause.  To change this
     attribute, use DEFINE FIELD to create a new field definition.
     Example 3 shows how to do this.

 When you change a field definition, this change will be visible to
 other users only after they invoke the database the next time.

 Depending on the type of change you make, you may have to reprocess
 the application programs that refer to the changed fields.

 You can change a field definition only if you have invoked the
 database that includes the field definition.  You must execute this
 statement in a READ_WRITE transaction.  If there is no active
 transaction, and you issue this statement, Rdb/VMS starts a
 READ_WRITE transaction implicitly.

Format

 CHANGE FIELD   ──> name ──┐
               ┌───────────┘
               └──┬───────────────>───────────────┬─┐
                  └─> 
D

E

S

C

R

I

P

T

I

O

N
typebox (I)typebox (S) typebox (/)typebox (*) text */ ──┘ │ ┌──────────────────<─────────────────┘ └─> field-attributes ──> .

Additional information available:

field-attributes

field-attributes

 field-attributes =

 ───┬────┬───> 
D

A

T

A

T

Y

P

E
typebox (I)typebox (S) ──> data-type ───┬──┬───> │ ├───> missing-value-clause ────────┤ │ │ └───> dtr-clause ──────────────────┘ │ └─────────────────────<────────────────────┘ A list of definitions that indicate what type of data you can store in the field and how Rdb/VMS uses that data. Ask for HELP on Field_attr or see the VAX Rdb/VMS Reference Manual for a complete description of field attributes. If you do not change a field attribute in the CHANGE FIELD statement, the attribute remains the same.

Additional information available:

data-typedtr-clausemissing-value-clause

data-type

 The data type of the field.  When you change a data type
 specification, Rdb/VMS automatically converts all the data in all the
 fields that use the global field definition the first time it is
 accessed.  Normally, Rdb/VMS converts any data type to any other data
 type.  However, some precision may be lost in the process of
 conversion.  For example, if you change from G_floating to F_floating
 data, Rdb/VMS rounds values.  If you change back to G_floating, the
 rounded data is converted.  The new values, therefore, differ from
 the original values.

Additional information available:

Format

Format
 data-type =

 ──┬───> 
S

I

G

N

E

D

W

O

R

D
──────┬───────────────────┬──────────────┬──> │ └──> 
S

C

A

L

E
──> n ───┘ │ ├───> 
S

I

G

N

E

D

L

O

N

G

W

O

R

D
──┬───────────────────┬──────────────┤ │ └──> 
S

C

A

L

E
──> n ───┘ │ ├───> 
S

I

G

N

E

D

Q

U

A

D

W

O

R

D
──┬───────────────────┬──────────────┤ │ └──> 
S

C

A

L

E
──> n ───┘ │ ├─┬─> 
F

F

L

O

A

T

I

N

G
─────┬────────────────────────────────────┤ │ └─> 
R

E

A

L
───────────┘ │ ├───> 
G

F

L

O

A

T

I

N

G
──────────────────────────────────────────┤ ├───> 
D

A

T

E
────────────────────────────────────────────────┤ ├───> 
T

E

X

T
────> typebox (S)typebox (I)typebox (Z)typebox (E) typebox (I)typebox (S) ───> n ───> typebox (C)typebox (H)typebox (A)typebox (R)typebox (A)typebox (C)typebox (T)typebox (E)typebox (R)typebox (S) ───────────┤ └───> 
V

A

R

Y

I

N

G

S

T

R

I

N

G
───> typebox (S)typebox (I)typebox (Z)typebox (E) typebox (I)typebox (S) ───> n ───> typebox (C)typebox (H)typebox (A)typebox (R)typebox (A)typebox (C)typebox (T)typebox (E)typebox (R)typebox (S) ──┘

dtr-clause

 DATATRIEVE support clauses.  For a complete description of the
 DATATRIEVE clauses, ask for HELP on Field_attr.

missing-value-clause

 missing-value-clause =

   ──┬──> 
M

I

S

S

I

N

G

V

A

L

U

E
typebox (I)typebox (S) ───┬───> fxd-pnt-num ─────┬───> │ └───> quoted-string ───┤ └──> 
N

O

M

I

S

S

I

N

G

V

A

L

U

E
──────────────────────────┘

Examples

 Example 1

 The following example expands the POSTAL_CODE field to nine
 characters and adds DATATRIEVE support characteristics:

 RDO>  SHOW FIELDS POSTAL_CODE
      POSTAL_CODE                              text size is  5
 RDO>  CHANGE FIELD POSTAL_CODE
 cont>    DATATYPE IS TEXT SIZE IS 9 CHARACTERS
 cont>    DEFAULT_VALUE FOR DTR IS "000000000"
 cont>    EDIT_STRING FOR DTR IS "XXXXX-XXXX".
 RDO>  SHOW FIELDS POSTAL_CODE
      POSTAL_CODE                              text size is  9
        edit string     XXXXX-XXXX
        default value   000000000
 RDO>  FOR E IN EMPLOYEES PRINT E.POSTAL_CODE END-FOR
  03817
  03817
  03301
  03456
 ^C
 %RDO-F-CABORT, user entered Control-C to abort command
 RDO>  STORE E IN EMPLOYEES USING
 cont>   E.LAST_NAME = "Forester";
 cont>   E.EMPLOYEE_ID = "00876";
 cont>   E.POSTAL_CODE = "039875573"
 cont> END_STORE
 RDO>  FOR E IN EMPLOYEES
 cont>    WITH E.LAST_NAME = "Forester" OR
 cont>    E.LAST_NAME = "Toliver"
 cont> PRINT
 cont>    E.EMPLOYEE_ID,
 cont>    E.POSTAL_CODE
 cont> END_FOR
  00876   039875573
  00164   03817
  00280   00000
  00347   03602
  00400   03457

 The field remains a text field, but the length is increased to nine
 characters, and an edit string and default value are specified for
 DATATRIEVE.  When you display the data, existing field values are
 padded on the right with spaces.  Thus an existing postal code would
 appear as "03104    ".  Newly stored values can have nine characters.


 Example 2

 The accounting department has decided that the BUDGET field will now
 include pennies:

 RDO> SHOW FIELDS BUDGET
      BUDGET                           signed longword scale  0
        edit string     $$$,$$$,$$$
 RDO>  FOR D IN DEPARTMENTS
 cont>   WITH D.DEPARTMENT_NAME = 'Manufacturing'
 cont> PRINT D.BUDGET_ACTUAL END_FOR
  190104
 RDO>  CHANGE FIELD BUDGET
 cont> DATATYPE IS SIGNED LONGWORD SCALE -2
 cont> EDIT_STRING FOR DTR IS "$$$$,$$9.99".
 RDO>  SHOW FIELDS BUDGET
      BUDGET                           signed longword scale  -2
        edit string     $$$$,$$9.99
 RDO>  FOR D IN DEPARTMENTS
 cont>   WITH D.DEPARTMENT_NAME = 'Manufacturing'
 cont> PRINT D.BUDGET_ACTUAL END_FOR
  190104.00


 Example 3

 You cannot change the VALID IF clause directly.  However, you can use
 DEFINE FIELD and CHANGE RELATION together to achieve the same result.
 The disadvantage of this method is that you must change each relation
 definition where the new field occurs.  You cannot change a VALID IF
 clause if the field already contains data that violates the VALID IF
 you are attempting to define.

 START_TRANS READ_WRITE RESERVING
 EMPLOYEES FOR EXCLUSIVE WRITE
 !
 ! 1.
 DEFINE FIELD TEMP_CODE
         DESCRIPTION IS /* Temporary field */
         DATATYPE IS TEXT SIZE IS 5.
 !
 ! 2.
 CHANGE RELATION EMPLOYEES.
   DEFINE TEMP_CODE.
 END.
 !
 ! 3.
 FOR E IN EMPLOYEES
   MODIFY E USING
     E.TEMP_CODE = E.POSTAL_CODE
   END-MODIFY
 END-FOR
 !
 ! 4.
 CHANGE RELATION EMPLOYEES.
   DELETE POSTAL_CODE.
 END.
 !
 ! 5.
 DELETE FIELD POSTAL_CODE.
 !
 ! 6.
 DEFINE FIELD POSTAL_CODE
         DESCRIPTION IS /* postal code */
         DATATYPE IS TEXT SIZE IS 5
         VALID IF POSTAL_CODE STARTING WITH "03".
 !
 ! 7.
 CHANGE RELATION EMPLOYEES.
   DEFINE POSTAL_CODE.
 END.
 !
 ! 8.
 FOR E IN EMPLOYEES
   MODIFY E USING
     E.POSTAL_CODE = E.TEMP_CODE
   END-MODIFY
 END-FOR
 !
 ! 9.
 CHANGE RELATION EMPLOYEES.
   DELETE TEMP_CODE.
 END.
 !
 COMMIT

 This sequence performs the following actions:

  o  Defines a temporary field to store the values while you modify
     the original field definition.

  o  Adds the temporary field to EMPLOYEES.

  o  Copies the values from the current POSTAL_CODE field to the
     temporary field, using MODIFY.

  o  Deletes the POSTAL_CODE field from EMPLOYEES, including the data.

  o  Deletes the global POSTAL_CODE field from the database.  If you
     try this example on a real database, Rdb/VMS returns an error,
     because POSTAL_CODE is also used in the COLLEGES relation.  You
     would have to perform steps one through four on COLLEGES before
     performing this step.

  o  Defines a new global field called POSTAL_CODE, whose definition
     includes the new VALID IF clause.

  o  Adds the definition for POSTAL_CODE to the EMPLOYEES relation.
     You now have two fields in EMPLOYEES with the desired definition.
     TEMP_CODE has data in it, POSTAL_CODE does not.

  o  Copies the data from TEMP_CODE to POSTAL_CODE using MODIFY.
     Rdb/VMS checks the validity of the data while the MODIFY
     statement executes.

  o  Deletes TEMP_CODE and commits the transaction.

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026