|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
