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).
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.