DSXchange

But still i am unable to understand the relationship here between job failure and transformer. Because the Transformer is the active stage in the job. You'll see that if you search for the actual processes that are created when your job runs. So any job failure will be reported by these 'active' pr...

You are going to need to be more specific about your issue, what you are seeing. Make sure you are pointing this installation to the location of your previous installation. Also note that I don't recall there being much (if any) verbiage related to 'upgrading', you basically install this version rig...

Any idea what the max data size is you'll be pulling from the CLOB for this job? Is your data source 10g by any chance?

The ODBC stage is very forgiving of binding issues. Others are very picky. For a lookup, you'll need as many ? bind parameters as you have Key fields defined.

<Thinks>
Cheater, cheater, pumpkin eater.
</Thinks>

And don't forget that you only get access to the Selection tab for hashed fields that were created in an account. Or ones you've explicitly created a VOC record for.

I for one don't see the connection between the two options and the APT variable issue. I know, back in my younger and foolisher days, I've used both without knowing better and it didn't throw that error. Maybe it helps I don't have PX, only a Server license. Put both back, see if the error repeats. ...

Again, there is no such thing as "Oracle format". And there is an option in Toad to pull DATE fields out in a multitude of formats, MM/DD/YYYY is just one of them. It's doing the same thing DataStage is doing, an explicit mask and a TO_CHAR() in the select.

And as an added bonus, those file transfer utilities can typically do the EBCDIC to ASCII transfer on the fly so you don't have to.

[sigh] Oracle does not want any kind of 'internal' format. Oracle does not want dates in MM/DD/YYYY format. At a very high level, Oracle doesn't care, it just wants to be told what format to expect. DataStage on the other hand *is* expecting a certain format for Timestamp datatypes, which is after a...

Add this as the first line of your routine:

Please post some specific examples so we can understand what you are seeing.

Ok, true. Point was to not rip apart the job and change the target (whatever it is) but to simply add the constraint.

No need to remove the target OCI stage. Just do as Ken suggested and change your constraint(s) to @FALSE - literally. That will shut down the target half of your job and you can see how quickly your current settings can pull data out of your database.

A UV stage over the hashed file will allow SQL to be run against the hashed data. A couple of caveats - the hashed file will need to be in an 'account' or have a VOC record built for it. And it will more than likely be slow without specific indexes built to support the queries. Search for forum for ...