Re: Weird problem a customer is having with a file (James H H Lampert)

A fellow List member discovered (and gave me privately, or 
I'd say who) a key piece of the puzzle: by using SEESAVF 
on the save file, he was able to see the raw internal 
represneation of the date field in the "problem" record 
(i.e. the Scaliger number), which appears to correspond to 
a date of January 1st. A.D. 0001.

According to the customer, the field in the original file 
is a type-L date field with no keywords specified at all: 
not null-capable, and default date format (which, at least 
on our boxes, is YYYY-MM-DD).

What I think happened is that somehow, in his query, he 
tried to convert the field to a 2-digit-year *YMD format, 
but the file contained at least one date field that's 
unrepresentable in that format. Somehow, instead of 
failing outright with an error message, it spat out a 
record with an unrepresentable date.

That still doesn't explain how a "2" got into the nullmap 
on a file that doesn't have any null-capable fields, but 
it's a plausable explanation, and indeed, the presence of 
a "2" in the nullmap may simply tell me that the record 
has data in a particular field that's so badly screwed up 
that it can't be unscrewed (other than maybe by SQL), and 
that the record is uneditable (except maybe through SQL).


--
JHHL
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.