DSXchange

'Irrespective of input data' sounds like a one time process, something you could do with a tool or a sql script. Then just build a normal load job for the 'new' data. That same script could be run before-job or you could build a separate job that runs first just to do that. Or... create a separate o...

Post your actual derivation, not "something like" it. That and the abort when you use it.

Same advice applies: Separate, convert, combine. First off, what is your source for this field? If it is also Oracle, then you can save yourself all this work just by selecting it properly in the first place.

You have to split the timestamp into date and time, convert them separately and then cat them back together. For you, all you need to handle is the time portion since the date isn't be reformatted.

Right, that really isn't an Oracle or sqlldr error, more of a DataStage one having problems trying to feed sqlldr. And probably a scratch space issue as Ray noted, if I had to guess.

If both of your dates are indeed in YYYY-MM-DD format and not null, than any comparison can be made in a constraint including 'non-equality'. Are you certain of your facts?

As noted, a hashed file can accept that much data. However, for that volume, you would probably be better off loading it into a work table and joining in your source database, if that's possible.

Or just move them elsewhere. I move old or obsoleted statements of that type into the Description box on a General tab, with comments as to where it came from and when/why it was removed.

Your other post implied the input data would drive the deletes but this seems to contradict that. How will you know what needs to be deleted?

Depends on your Auto-Purge settings for that job. Check from the Director.

Not so weird. Try searching on something like "previously undefined. Zero used.".

Yup. Just wanted to ask as it's bit me in the ass before.

Still wondering if this is the infamous HP-UX and $LD_PRELOAD problem.

There's another patch for that. Oh, and I did find the ecase for the SP2 patch: 60128. That should help them locate it.

They were unable to identify the patch? Tell them you need the "Windows XP service pack 2" patch for the client, I have no idea what the number is.