F. Alfredo Rego wrote:
>
> Fred White and I are polishing up the final details of Adager's
> contribution to the year-2000 challenge and we need your collective help
> regarding a thorny issue.
>>>snip>
> Should we flag these values as "illegal" and convert them to 19991232 (or
> some such impossible and arbitrary date)?
No. Don't convert illegal dates.
> The consequences are horrible.
By this I think you mean "how do I flag invalid dates that were never
intended to be dates?"
Leave them alone and apply the rules of the field type when expanded, i.e.,
blank fill on X type. Right or Left fill? Do what ADAGER does now for
expanding an X field. Keep the fill consistent or invent syntax options to
let the user decide.
The other variation: "how do I flag invalid dates that _were_ intended to be
dates?"
Again, leave them alone and apply the rules of the field type when expanded,
i.e., blank fill on X type. I think the user should have this responsibility
for clean-up. A date conversion utility should do only one thing, convert
_valid_ dates.
> For instance, different master-search-field values would collapse into one
> value and dangling orphan detail chains would result.
Leave them as they were, this problem is not yours.
> The date-converting
> procedures would "feel good", though, because they would not have
> contaminated themselves with non-DATE values and they would have washed
> their hands, perhaps with YOUR blood :-)
Boy, you did say PHILOSOPHICAL?, I guess you meant it.
>In all of these cases, you would have to change the tests in
> your applications anyway.
Yes, Changing an X6 to X8 would do this. No magic bullet.
>
> What do YOU say?
>
> Hopefully, this small tasting will give you an idea of the flavors to come.
Water under the bridge, mind you, but if IMAGE had a DATE function (or any
function like USER, SEQUENCE, etc. for the sake of consistency would be
nice) that would auto-fill a field when a <null> is passed to it on DBPUT or
DBUPDATE, things might look a lot different now.
Functions would need to become part of the IMAGE schema definition and
stored in the root file. No way around this.
----------------------------------------------------------------
Eric J. Schubert Senior Data Base Analyst
Office of Information Technologies Univ of Notre Dame, IN USA
(219) 631-7306 http://www.nd.edu/~eschuber
----------------------------------------------------------------
Eric J. Schubert Senior Data Base Analyst
Office of Information Technologies Univ of Notre Dame, IN USA
(219) 631-7306 http://www.nd.edu/~eschuber
|
