DSXchange

Not supported. It will work on XP Pro but not Home.

So this patch is specific to 8.x yes?

Just as a sqlldr FYI - that is true enough for a direct path load, however a conventional (DIRECT=FALSE) load does commits and the commit interval is user configurable.

Yes, as noted, clearing will resolve the corruption. The log file has nothing to do with compilation, but rather it is created when the job is created and populated at runtime. And if you 'clear' it all data in it would be gone, of course. Not sure if that answers your question or not, however. ps. ...

Not legally, no. No clue if/how v8 enforces that any more.

And yes, it will use the 'whole capabilities'.

Commenting it out of the dsenv won't affect any other applications, just DataStage. You'd need to talk to an SA about what exactly it does other than cause core dumps.

Good to know.

Was wondering about something like that, but the docs didn't give much of hint that you could do that. Or maybe I just need a +1 to my reading comprehension skill.

If you have $LD_PRELOAD set, try unsetting it.

Sure sounds that way... off to sqlldr land you go!

Or just click on 'Usage Analysis'.

Too many variables specific to your database and hardware to make recommendations like that.

Goodness, 5.2... who remembers. Does this version of the stage have an 'automatic' versus 'manual' mode? If so, automatic actually loads the data and manual only creates the .dat and .ctl files, you need to load them via sqlldr yourself afterwards. Based on what you posted from the readme, it sounds...

No, not really. Is this only a problem for you or does this happen to everyone?

So... you have a single Oracle script all jobs should use or different ones for different situations? Still suggest you search for previous NLS_LANG conversations, see if any help.

What have you tried? Short answer is convert both to internal format and subtract. And as to your 'target column is a number'... of what? Difference in days? If so, then you should be fine if you do as noted.