DSXchange

That should do it, I would think. What does the sqlldr .log file say for the load, what options were in play when it ran?

Since generated SQL can't bind the same column twice, include it twice in your link (old and new values) then use user-defined SQL to do the actual update in the target stage.

Ok... so, here we are in the proper forum and I edited your original post to reflect the proper Job Type. That being said, try adding APT_ORACLE_PRESERVE_BLANKS to your job and setting it to True, see if that helps.

So... a PX job?

Right, simply read it in with one delimiter and write it back out with the other. Have you tried this? What issues are you having?

What exactly do you want it to do when it runs on multiple nodes? Typically you want the 'round robin' effect that anbu mentioned, i.e.

Node 1: 1,5,9,13
Node 2: 2,6,10,14
Node 3: 3,7,11,15
Node 4: 4,8,12,16

However, it seems like you want something else?

Then if you've done this combination before and it works but things are not working on this particular server then it seems like we're back to a configuration problem, most likely in your "shared library" environment variable I would think. As Arnd noted, I would triple-check your dsenv fi...

Not to side-track things but neither does recompiling a job, Server or otherwise (regardless of where the logs are stored), so not quite sure what jdmiceli was thinking of.

Yah, this should be pretty simple to set up and operate, most of us have something like this in our toolkits, I'd wager. :wink: One word of advice: when you do this make sure you filter out the name of the job that is doing the actually checking and don't attempt to interogate it as doing things lik...

If '0001' is your lowest possible value for that field, sort ascending on it and always pick the first duplicate as noted earlier.

I have no idea what is what anymore, 64 v. 32, however if everything is 64bit now on that platform then you should be fine leveraging the 64bit Oracle drivers.

If this 'particular FTP location' is somewhere on the DataStage server, then you can handle that with proper pathing in the output stage. Otherwise, you'll need to create it somewhere and then transfer it in some sort of 'after job' activity, which could be a script that leverages FTP or scp or some...

Your Oracle "bit-ness" doesn't matter, what matters is if DataStage itself is 32bit or 64bit, you'll need to match your drivers to that.

Only one client "works" or is active at any given time and the MCM is used to switch from one to the other.

Oracle will do that by default and there is a property called "preserve blanks" off the top of my head that will stop it from happening. What stage are you writing to Oracle with and is this a Server or PX job?

ps. I edited your subject to be more meaningful.