|
|||
|
My dbimport failed since somebody had brilliantly changed the default
DBDATE when exporting to something other than the conventional default -- but some date-type cols in schema were defined like: expire_dt DATE DEFAULT '12/31/2099' NOT NULL -- hence the failure-inducing error since the default date string didn't match the DBDATE format. I ended up deleting the offending SQL, loading, changing DBDATE back, and adding the defaults back via alter statements. Is there a more portable way to declare such a default? I was hoping to be able to do something like: expire_dt DATE DEFAULT TODAY + UNITS 100 YEAR NOT NULL -- but syntax for defaults apparently doesn't support this. Does anyone have a way to get around this? I don't think this detail of the syntax has changed in later IDS versions. Further, I can't make assumptions about how the application is using the column, and, hence, what queries were written, and what would break if data type were changed, etc. A better solution would be for dbexport to error out prior to commencement after determining an incompatible default date format. Using IDS 10.00.FC6 on RHEL4 (yes, yes dated versions both -- perhaps you can speak to project poobahs about upgrade? We're too hoarse from repetition.) |
|
|
||||
|
||||
|
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|