Kbase P5650: INITIAL attribute of buffer-field is blank whereas schema in
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/06/2003 |
|
Status: Verified
SYMPTOM(s):
The INITIAL attribute of buffer-field object is blank
The INITIAL value of the field is unknown in the schema (data dictionary)
CAUSE:
Developers may expect the INITIAL attribute to hold ? (unknown) instead of blank however the documentation says:
"The value of the INITIAL schema field (which is always CHARACTER), formatted with the buffer-field's format. If the INITIAL schema field has the UNKNOWN value, the value of the INITIAL attribute is the null string ("")."
Next are few details for a better understanding:
The unknown initial values are indeed being copied ok with hBuffer:BUFFER-CREATE.
The reason that you think that initial is "NOT" unknown is that it is an attribute, which is indeed known and has a value which is the unknown value and that is represented as a blank for buffer field objects. The INITIAL attribute is a CHARACTER attribute, and buffer objects show unknowns as blanks when they have been converted to character.
We cannot change the way we represent unknowns for buffer objects because it was very deliberate and people depend on it. Thanks to that, it is easier to manage lists of initial values in character variables without bothering about a 'terrible' contagious unknown value. (ADM2 may rely on this) Lastly, it is a good deal because unknown values for character fields are hardly ever used.
FIX:
For INTEGER, DECIMAL and DATE data types, this blank initial value can easily be taken as unknown. It is more problematic when considering a CHARACTER field and when blank does not mean unknown at all. However, if the internal version of the initial value is really needed, it can be obtained from the corresponding metaschema _field record or from the buffer-value of a freshly created record (in a temp-table defined with LIKE option, for instance).