Timestamp mess in the Basic transformation

Task

 Set the UserStatus with the serialisation of values containing timestamps.

Problem

I only know the possibility to set the UserSTatus by the use of DSSetUserStatus. This in turn has to be put into a routine, that in turn cannot be placed into the modern transformation, but one needs to use the Basic flavour (see also https://gssnotes.blogspot.com/2010/06/enable-basic-transformer-in-datastage.html). Unfortunately, this is allergic to timestamp: "Returned timestamp format not recognised for field <XYZ>"

Solution

Place the Basic transformation in a dead end as the "final" stage like

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Missing record delimiter "\n", saw EOF instead

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.
Mehr anzeigen

Sequential file stage does not output the entire line

Bild
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.
Mehr anzeigen

Error when checking operator: Could not find input field 'field_name'

Well, you checked and double-checked the existence of respective field and it is there! Yeah, stumbled over it again. And again! Possible solutions You need to compile jobs explicitly. You're done then. Try it. Go! What are you waiting for? If you are really extra sure compiled the job, then double-check the presence of the respective field again, but not in the stage DS tells you but in the very source at the start of the dataflow where this field comes from. It happens that if the column name of your SQL is not identical to the field name propagated. I do absolutely not know why: compilation does not reveal the problem DataStage misses the correct problem location by far
Mehr anzeigen