DSXchange

"TRANS2" is your second Transformer stage, if that helps narrow it down at all. You could also go read that "JOB" file directly to see what code / derivation is causing the issue. You can find it in your RT_BP2205 directory in the job's Project, check at / around line 302 as noted.

So... just to confirm. These "lookuptable" files are of no use after the job completes and can be simply deleted from the O/S without issue, correct? And by that I mean without "orphaning" anything like you can if you delete a fileset or dataset incorrectly.

Ah... gotcha.

OK, other performance related questions - indexes, are there many on the table? What kind/complexity? Are there FK constraints on this table? Triggers? All things that could rob you of speed during a load.

So... did you get this worked out?

[cricket, cricket]

So... would this help at all?

For the Enterprise stage, the 'drivers' you'd need is the Oracle client and you always get one of those.

tostay2003 wrote:Since dataset doesn't get created when no records are written to it due to constraints in transformer (or any other stage).

This is not correct.

Not sure what 11g has to do with ODBC. Have you been told the Oracle Enterprise stage won't work with 11g? Have you tried to use it and had issues?

Your syntax looks fine as long as the path is correct. Try it again adding the OVERWRITING keyword to the end and see if that helps, the new one may not have actually replaced the old one.

I would guess that either your lookup constraint logic is faulty or the hashed file hasn't been populated correctly. Forced to guess due to an extreme lack of details.

You seem to be missing the back-slash between "7.5.2" and the dsexport command.

Exactly.

No it doesn't, you just think it does.

Eight dot five? So, sometime after the Apocalypse in 2012.