Kbase P161455: ADD FIELD Online Fails if Field ORDER Already Exists
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/25/2010 |
|
Status: Verified
SYMPTOM(s):
ADD FIELD Online Fails if Field ORDER Already Exists error 388
Incremental df contains same ORDER as an existing field
Database in use by <user> on <tty>. Wait or press <STOP> to stop. (388)
Incremental df load changes ORDER value for some fields
FACT(s) (Environment):
Schema change is done either fom data dictionary with "Add Objects online" or manually:
SESSION:SCHEMA-CHANGE = "New Objects".
Offline changes change the order value automatically.
All Supported Operating Systems
Progress/OpenEdge Versions
CAUSE:
The schema-lock cannot be relaxed under these conditions as existing fields need to be modified.
The ORDER specified in the .df is absolute for that field.
For example, if a field is added with ORDER 90, and a field is already assigned ORDER 90, all existing fields need to be 'shifted', not just the one that already has ORDER 90 as we increment the ORDER +1.
#load1
myfield1 10 92
myfield2 11 91
*myfield3 12 90* << new field gets ORDER in the .df file.
#load2
myfield1 10 93
myfield2 11 92
myfield3 12 91
*myfield4 13 90 *<< new field gets ORDER in the .df file.
The load utility is a linear (top down) process and handles deletes after creates and updates. When it sees a duplicate ORDER number it always pushes the existing one up one digit to avoid errors. When this happens and there is another field with an ORDER value only one digit higher, then it's value gets incremented by one, thus making it one higher than expected. (Note how myfield2 has incremented from ORDER 90 to ORDER 93 by the time we've added myfield4).
In OE10.1C01+ OE10.2A+, an additional check has been implemented to the load functionality. When an ORDER value is free (either because an existing field's ORDER got changed or the field record got deleted), we try to reassign that ORDER one more time to see if we can keep the intended values. This verifies a very specific situation where the ORDER values become available. If not the case, the existing one is pushed up one digit to avoid errors. This results in the field ORDERs no longer matching the source database and CRC differences will result.
So in effect, during the adding of this field online, the schema-lock cannot be relaxed as existing fields need to be updated.
FIX:
Always use the three database method to deploy changes to your database. This is the only way to always ensure that the .df between the delployment (or control database) and production are always in sync ie: your control database is identical to what you've deployed.