Abbreviated years and expressions in database objects
When an expression in a database object (including a check constraint, fragmentation expression, SPL routine, trigger, or UDR) contains a literal date or DATETIME value in which the year has one or two digits, the database server evaluates the expression using the setting that DBCENTURY (and other relevant environment variables) had when the database object was created (or was last modified).
If DBCENTURY has been reset to a new value, the new value is ignored when the abbreviated year is expanded.
birthdate < '09/25/50'
The expression is interpreted according to the value of DBCENTURY when
the constraint was defined. If the table that contains the birthdate column
is created on 09/23/2000 and DBCENTURY =C
,
the check constraint expression is consistently interpreted as birthdate <
'09/25/1950'
when inserts or updates are performed on the birthdate column.
Even if different values of DBCENTURY are set
when users perform inserts or updates on the birthdate column,
the constraint expression is interpreted according to the setting
at the time when the check constraint was defined (or was last modified).
Database objects created on some earlier versions of HCL OneDB™ do not support the priority of creation-time settings.
For legacy objects to acquire this feature
- Drop the objects.
- Recreate them (or for fragmentation expressions, detach them and then reattach them).
After the objects are redefined, date literals within expressions of the objects will be interpreted according to the environment at the time when the object was created or was last modified. Otherwise, their behavior will depend on the runtime environment and might become inconsistent if this changes.
Administration of a database that includes a mix of legacy objects and new objects might become difficult because of differences between the new and the old behavior for evaluating date expressions. To avoid this, it is recommended that you redefine any legacy objects.