Changes the storage map definition for a relation.  You can also
 change which index Rdb/VMS uses when it stores new records whether
 records will be stored in a compressed format, and whether data will
 be reorganized.

Additional information available:

FormatMoreExamples

 CHANGE STORAGE MAP map-name ──>──┐
 ┌────────────────────────────────┘
 └┬───────────>──────────┬─┬───────────────>──────────────┬┐
  └> map-storage-clause ─┘ └> change-relation-map-clause ─┘│
 ┌───────────────────────────<─────────────────────────────┘
 └─> 
E
N
D ─────┬────────>──────┬─────> typebox (S)typebox (T)typebox (O)typebox (R)typebox (A)typebox (G)typebox (E) typebox (M)typebox (A)typebox (P) ────> .
              └─> map-name ───┘

Additional information available:

map-namemap-storage-clausechange-relation-map-clause

 The name of the storage map you want to modify.

 map-storage-clause =

 STORE ─┬> map-within-clause ──────────────────────────┬─┐
        └> 
U
S
I
N
G ─┬> field-name ─┬> map-within-clause ─┘ │
                  └───── , <─────┘                       │
  ┌────────────────────────<─────────────────────────────┘
  └─┬─────────────>──────────────┬──>
    └> default-threshold-clause ─┘

 Used to define a storage map.  This clause lets you specify which
 storage area files will be used to store rows from the relation:

  o  All rows of a relation can be associated with a single storage
     area.

  o  Rows of a relation can be randomly distributed among several
     storage areas.

  o  Rows of a relation can be systematically distributed, or
     partitioned, among several storage areas by specifying upper
     limits on the values for a column in a particular storage area.
     This is called horizontal partitioning.

 If you omit the storage map definition, the default is to store all
 the rows for a relation in the main RDB$SYSTEM storage area.

Additional information available:

map-within-clauseUSING field-namedefault-threshold-clause

 map-within-clause =

 WITHIN ─┬─> area-name ─┬──────────────>───────────────┬─┐
         │              └> 
W
I
T
H 
L
I
M
I
T typebox (O)F ─┬> literal ─┬┘ │
         │                                └──── , <───┘  │
         │┌───────────────────────<──────────────────────┘
         │└┬──────────────────────>──────────────────┬─┬─┐
         │ └─> 
F
O
R ─┬─┬─┬> rel-name ─┬───────────────┤ │ │
         │          │ │ └──── , <────┘               │ │ │
         │          │ └┬> relation-name.field-name ─┬┘ │ │
         │          │  └──────────── , <────────────┘  │ │
         │          └──────────── , <──────────────────┘ │
         │ ┌────────────────────────<────────────────────┘
         │ └─┬──────────>──────────┬──┬─────────>
         │   └─> threshold-clause ─┘  │
         └───────────── typebox (;) <───────────┘

Additional information available:

WITH_LIMIT_OF

area-namerel-namerelation-name.field-namethreshold-clause

 The name of the storage area you want records stored in.  You must
 have defined this storage area with either the DEFINE DATABASE
 statement or the DEFINE STORAGE AREA clause of the CHANGE DATABASE
 statement before you refer to it in the store clause.

 The maximum value for the index key that will reside in the specified
 storage area.

 The number of literals in this clause must be the less than or equal
 to the number of fields in the USING clause.  Repeat this clause to
 partition the index entries among multiple storage areas.

 When you define a multisegmented index using multiple keys and use
 the STORE USING...WITH LIMITS clauses, if the values for the first
 key are all the same, then set the limit for the first key at that
 value.  By doing this, you ensure that the value of the second key
 determines the storage area in which each record will be stored.

 Note that the last storage area you specify CANNOT have a WITH LIMIT
 OF clause associated with it.

 If you change the limits for a storage area, records that were
 already stored in the area are not moved according to the new limit
 clause.  However, new records will be stored into the relation
 according to the new limits you specify.

 The name of the relation whose segmented strings you want to store in
 the specified storage area.  If you want to store the segmented
 strings of more than one relation in the storage area, separate the
 names of the relations with commas.

 The name of the relation and segmented string field that you want to
 store in the specified storage area.  If you want to store more than
 one segmented string field in the storage area, separate the list
 items with commas.

 threshold-clause=

 ──> 
T
H
R
E
S
H
O
L
D
S typebox (A)typebox (R)typebox (E) ──────────┐
  ┌─────────────<─────────────┘
  └─> ( ──> val1 ─┬───────────>──────────┬─> ) ──>
                  └─> ,val2 ──┬─────>────┤
                              └─> ,val3 ─┘

 Specifies associated threshold values for each storage area with
 uniform format that is specified in the map-within-clause.  By
 setting threshold values, you can make sure that Rdb/VMS does not
 overlook a page with sufficient space to store compressed data.

 The threshold values specify when the page is marked as FULL in the
 SPAM page free space inventory lists.  For example, if you set
 default values of 70, 85, and 95 percent, ranges of guaranteed free
 space on each data page are 30, 15, and 5 percent, respectively.  If
 you do not set default values, the values are (0,0,0).  With values
 of (0,0,0), Rdb/VMS will use the record length when setting the SPAM
 fullness.  Rdb/VMS will never store a record on a page at threshold
 3.  The value you set for the highest threshold can be used to
 reserve space on the page for future record growth.

 If you specify a value of 40 for the "val1" parameter, but do not
 specify values for the "val2" or "val3" parameters, the threshold
 values will be set at (40,100,100).

 If you use data compression, you should use logical area thresholds
 to obtain optimum storage performance.

 The names of the fields whose values will be used as limits for
 partitioning the relation across multiple storage areas.  Rdb/VMS
 compares values in the fields to the values in the WITH LIMIT OF
 clause to determine where to initially store the record.

 default-threshold-clause =

 ──> 
D
E
F
A
U
L
T 
T
H
R
E
S
H
O
L
D
S typebox (A)typebox (R)typebox (E) ──┐
  ┌─────────────<─────────────┘
  └─> ( ──> val1 ─┬───────────>──────────┬─> ) ──>
                  └─> ,val2 ──┬─────>────┤
                              └─> ,val3 ─┘

 Specifies associated threshold values for each storage area with
 uniform format that is NOT specified in the map-within-clause.  By
 setting threshold values, you can make sure that Rdb/VMS does not
 overlook a page with sufficient space to store compressed data.

 The threshold values specify when the page is marked as FULL in the
 SPAM page free space inventory lists.  For example, if you set
 default values of 70, 85, and 95 percent, ranges of guaranteed free
 space on each data page are 30, 15, and 5 percent, respectively.  If
 you do not set default values, the values are (0,0,0).  With values
 of (0,0,0), Rdb/VMS will use the record length when setting the SPAM
 fullness.  Rdb/VMS will never store a record on a page at threshold
 3.  The value you set for the highest threshold can be used to
 reserve space on the page for future record growth.

 If you specify a value of 40 for the "val1" parameter, but do not
 specify values for the "val2" or "val3" parameters, the threshold
 values will be set at (40,100,100).

 If you use data compression, you should use logical area thresholds
 to obtain optimum storage performance.

 change-relation-map-clause =

 ──┬┬─> 
N
O 
P
L
A
C
E
M
E
N
T 
V
I
A 
I
N
D
E
X ───────────────┬─>
   │└─> 
P
L
A
C
E
M
E
N
T 
V
I
A 
I
N
D
E
X  ──> index-name ──┤
   ├┬─> 
D
I
S
A
B
L
E ──┬─> 
C
O
M
P
R
E
S
S
I
O
N ────────────┤
   │└─> 
E
N
A
B
L
E ───┘                           │
   └──> 
R
E
O
R
G
A
N
I
Z
E ─────┬──────>────┬─────────┘
                        ├─> 
A
R
E
A
S ──┤
                        └─> 
P
A
G
E
S ──┘

Additional information available:

PLACEMENT_VIA_INDEXNO_PLACEMENT_VIA_INDEX

COMPRESSION clauseREORGANIZE clause

 Indicates that Rdb/VMS should attempt to store a record in a way that
 optimizes access to that record via the indicated path.  Rdb/VMS
 chooses a target page for any record being stored by rules that take
 into account the type of index defined (sorted or hashed), the type
 of storage areas involved (uniform or mixed), and how indexes and
 relations are assigned to each other.

 The index named in the PLACEMENT VIA INDEX clause must be defined for
 the same relation that the storage map is being defined for.

 Negates the PLACEMENT VIA INDEX clause, so that subsequent records
 stored are not stored via the index named in the PLACEMENT VIA INDEX
 clause.  This option is only available on the CHANGE STORAGE MAP
 statement.  If you specify the CHANGE STORAGE MAP statement without
 the PLACEMENT VIA INDEX option or the NO PLACEMENT VIA INDEX option,
 the statement executes as if the clause specified on the DEFINE
 STORAGE MAP statement or last CHANGE STORAGE MAP statement had been
 used.

 Specifies whether data compression will be enabled or disabled for
 the records when they are stored.  ENABLE COMPRESSION is the default.

 Causes rows previously stored in specified relations to be moved
 according to the partitions specified in the CHANGE STORAGE MAP
 statement.

 To change a storage map for a relation with the CHANGE STORAGE MAP
 statement, you need the Rdb/VMS CHANGE privilege for the relation.

 If the database is created with the DICTIONARY IS REQUIRED option,
 you must invoke the database by path name, rather than file name,
 before you issue this statement.

 You must specify either a store-clause, a [NO]PLACEMENT VIA INDEX
 clause, a REORGANIZE clause, or a COMPRESSION clause in a CHANGE
 STORAGE MAP statement.

 In the change-relation-map-clause, you can select one or more of the
 three clauses ([NO]PLACEMENT VIA INDEX clause, REORGANIZE clause, or
 COMPRESSION clause) in any order, but you cannot repeat a clause.
 Note that when the REORGANIZE clause is used, records are moved and
 assigned to new dbkeys.

 If you omit the store-clause in the CHANGE STORAGE MAP statement, you
 can create a second index by mistake.

 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.

 Other users are allowed to be attached to the database when you issue
 the CHANGE STORAGE MAP statement.  However, they are not allowed to
 be using the relation whose map is being changed.

 Example 1

 The following example disables compression for the CANDIDATES_MAP
 storage map:

 RDO>  CHANGE STORAGE MAP CANDIDATES_MAP
 cont>   DISABLE COMPRESSION
 cont> END CANDIDATES_MAP STORAGE MAP.

 Example 2

 The following example assigns new limits for storage areas:

 RDO>  CHANGE STORAGE MAP EMPLOYEES_MAP
 cont>  STORE USING EMPLOYEE_ID
 cont>    WITHIN EMPIDS_LOW WITH LIMIT OF "00300";
 cont>           EMPIDS_MID WITH LIMIT OF "00600";
 cont>           EMPIDS_OVER
 cont> END EMPLOYEES_MAP STORAGE MAP.

 Current data will not be moved according to the new limits.  However,
 when new data is stored, it will be stored according to the new
 limits in the storage map.

 Example 3

 The following example defines a new storage area EMPIDS_MID2 to
 handle the employee IDs 600-900, and to reorganize the data from one
 existing storage area, EMPIDS_OVER.  The current data which is stored
 within the limits of employee IDs 601-900 will be moved according to
 the new limits.  When the new data is stored, it will be stored
 according to the new limits set in the storage map definition.

 RDO> CHANGE STORAGE MAP EMPLOYEES_MAP
 cont>  STORE USING EMPLOYEE_ID
 cont>        WITHIN EMPIDS_LOW WITH LIMIT of "00300";
 cont>           EMPIDS_MID WITH LIMIT OF "00600";
 cont>           EMPIDS_MID2 WITH LIMIT OF "00900";
 cont>           EMPIDS_OVER
 cont>           REORGANIZE
 cont> END EMPLOYEES_MAP STORAGE MAP.