DSXchange

Umm, at the risk of repeating myself - view data should not be used to test whether or not NLS characters are correclty represented.

Account names are also case-sensitive.

if your DataStage installation is elsewhere, should do the trick as well.

Hello and welcome to DSXChange.

There should be a log entry giving the actual column name. Does this column exist in both input links or in the reference link or in the source link? I seriously doubt that this is a bug, every time I've seen this error it has been due to incorrect design.

What were your NLS settings when you tried to view the data in DB2 and what tool/program did you use to display? Over half of the NLS issues I see are not really errors, but display problems. NLS isn't too complicated when you realize which NLS character set you are using in each stage. But you need...

You cannot view the log files directly. You can use the "dsjob" command with options such as "-logdetail" or "-logsum" to extract log information. Logs are purged manually or by using autopurge settings as set in the director.

In that case you can mark this thread as resolved and then open up a new thread with your new problem.

Where is it showing "??" - the "View Data" won't correctly display data. You will also need to provide a bit more information in order to get a good analysis as to where the conversion is going wrong (if at all).

Define a reject link to your output database stage and then you can see the SQL error message as well as the data that caused it.

Actually, the other way around - in PX you cannot define a reference stage to a transformer, while in server you can.

Thanks for that.

To add to what Ray has already said, another possibility is that you have runtime column propagation turned on and don't directly "see" the duplicated column name becuase it has been passed in from a previous stage.

If you had run out of space the job would have aborted. Have you monitored the system while the job is running - particularly disk IO and CPU usage? When the job "hung", how did you stop it?

Large sorts can take a long time...

Look at my query again, what about the "fund_dt < getdate()" part?

Although I would have used different filenames, your run looks good. The output indicates no data was truncated by the fix command and you just had group errors which were corrected. You might wish to delete or check the job "/backups/Shadi" after fixing your "live" DS_JOBOBJECTS...