DSXchange

Me, I would ask your asker what the heck that means.

All things being equal, I'd venture to guess it was the data and not the stage.

Just the normal stuff in dsenv is what is needed, as documented in the pdf manuals. So, can you use any of the Oracle stages in a job, like the OCI stage in a Server job or is that not working as well?

how about a McCulloch chainsaw, a Las Vegas wedding, a Mexican divorce, a solid gold Kama Sutra coffee pot, or a baby's arm holding an apple?

Make sure you're using the 32bit Oracle libraries unless you are certain that DataStage is also 64bit on your platform.

I've never seen it and it hasn't been posted here before. Perhaps this might help?

http://tinyurl.com/qm4eyy

I've seen the same bug and there *is* a client side patch for it, ask your support provider for it. Keep in mind it is a client patch that changes the compiled code in this case, so if someone else without the patch compiles your fixed job, it will be... unfixed.

Do you actually have an Oracle client installed on your DataStage server?

We're gonna need some help here, I've never heard of "EV4" either and Google isn't any help turning up explanations.

In other words, you'll need something executable from the command line of your O/S for DataStage to initiate the zip. The registered version of WinZip has that as an option, other tools exist as well.

Oy, you so right. I was speaking of the KeyMgmt routines in the sdk branch of the repository, the ones that create/leverage the aforementioned hashed file name, and not noticing that little discrepancy.

You need to set it back to 1 rather than increment it when the group changes. In other words, change that "else SVValue" to "else 1". That Initial Value is an 'at the moment the job starts' value.

From what I recall, but can't check now, is that you can specify 'custom' update/insert and then only include the insert. Better, of course, to prequalify your data and only do the inserts for key values that don't already exist. Me, I would never build something that would purposefully violate RI c...

Since there's no real 'aggregation' - a couple of thoughts are here, more can be found by searching for 'key change column'.

Sure, you could 'cheat' and demote them with a message handler. Doesn't change the Best Practice of handling them properly in your job and the need to update jobs when RI changes is just part of the game, I'm afraid.