Kbase P156059: How do we assign a POSITION to a field when loading a .df file when it is not specified in the .df ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
18/11/2009 |
|
Status: Unverified
GOAL:
How do we assign a POSITION to a field when loading a .df file when it is not specified in the .df ?
GOAL:
How does the mechanism/algorithm of assigning a POSITION to a field work?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
The v8 binary dump/load did not use the table's CRC to validate the tables upon load, but the v9 and above load does.
If the field position is not set, then we pick a value based on the number of fields in the db (numflds), and assign them in the order they were loaded into the db.
Please note the following:
1. For a new, empty table we will always assign POSITION 2 to the first field because POSITION 1 is reserved internally
2. The value for numflds is like a High Water Mark, the only way to "reset" it is by dumping and loading the DB. Deleting a field will not decrease the numflds value.
3. When loading a .df that contains new fields:
First, we sequentially assign a POSITION to each new field that does not have a POSITION specified in the .df file.The POSITION will be = numflds + 1 .
(If a POSITION is explicitely defined in the .df but already exists in the table , we abort and display an error message.)
Second, should the POSITION that we assigned already exist in the table we will increment the POSITION to the next available value.
An example:
A DB used to have 40 fields in a specific table, however during its lifetime one of the fields was removed (this field had POSITION 38).
For this database the number of fields (numflds) is still 40.
When this DB is then dumped and loaded (e.g. into a new structure during an update from v8 to v10) only the existing fields are actually loaded (not the one that deleted obviously) but we keep their original POSITION. That means the value for numflds for the new DB is then 39 but the last POSITION assigned is still 40.
Now, if one was to load two new fields (field A and field B) into the old v8 DB with a .df that does not explicitely assign POSITIONS to the fields, then field A would get POSITION 41 and field B would get POSITION 42.
If one was to load the very same .df into the v10 DB however, the outcome would be different. As numflds is 39 for the v10 DB we will try to assign POSITION 40 to A and POSITION 41 to B. Now, in this particular case POSITION 40 was already taken up and we already reserved POSITION 41 for field B, so field A now receives POSITION 42.