While debugging the otherproblems, I noticed the peek to output spaces for a char column even though the very same value written to the database was NULL. Surprising twist...
Actually, this warning is quite simple to fix. Apparently, DS expects the last record of a file to terminate with the record delimiter in any case - maybe there is a setting to alter this behaviour but I did not deem worthwhile the effort to look for it. So the solution is just to terminate the file on a single empty line. Obviously, this case is for Unix like line breaks. The others delimiters are handled analogously.
Symptom A sequential file stage issues the following warning and reads records only incompletely. Import consumed only 13bytes of the record's 46 bytes (no further warnings will be generated from this partition) The number of bytes depends on the actual file. Cause I speculate that the codepage processing implementation is queer. I could not find a subproperty neither in the properties nor format tab to specify the codepage the file is expected in. But... Solution one can specify a Unicode codepage in the extend field of the columns of the columns tab.
Well, I just adapted a job where the Change Capture stage is being used. My test data contain NULL as values to be compared against. I was very much surprised that the comparison with NULL results in finding no difference even though - to the best of my knowledge - SQL standard requires that such comparison always return non-equality. I know, DataStage is no SQL database but then again it is a tool heavily (I suspect mainly) being used in connection with SQL databases (at least as of writing this) and thus it would have been nice and straight forward if it followed the SQL standard where applicable. Please let me know if your experience is with respect to Change Capture stage and NULL is different. My observation is that counter-intuitive to me, that it make me unsure whether I misinterpreted the results.
Kommentare
Kommentar veröffentlichen