DSXchange

And now they're back, and a couple of new ones too.

There's nothing "out there" of which I'm aware as a parallel routine. It may be best to create a Build stage, since you're going to have to discover the metadata as well as to process the data records. One tip (from IOD2008): unless you have reason not to, always write BuildOps as combinab...

OK, is there anything interesting in /dsdata/Scratch/Files/ora.680136.208331.0.log ?

"They" probably lost it when the added the Editor's BLOG. I'm sure "they" will put it back shortly. Indeed, there's a whole category of forums that have vanished - all of what used to the the "peripheral tools" like ProfileStage/Information Analyzer and MetaStage.

Oracle bin Larry

You could, but you might need to allow for blocking factor. Probably the Complex Flat File stage can manage this.

At worst you could write a DataStage BASIC routine and use its low level READT statement.

Or even easier a server job loading a multi-valued field and reading it normalized.

Should VARCHAR be VARCHAR2 ?

Are you certain that you have a Solaris version of DataStage server?

Also the generated pathname contains a double slash. Not all UNIXes can manage this.

I can still only suggest creating a server routine (and invoke it from a Routine activity) to read the job sequence's log.

Sure. Find out what's wrong with the data. It's something DataStage does not know how to handle. Check that the metadata in your job design precisely matches what you imported from Teradata.

Only that there was no mention of a Sort stage in the original question. Without a Sort stage you don't get a KeyChange column. But it would be a viable solution.

It is NEVER true. Oracle is wrong.

You will need an ODBC trace to verify this, but I suspect that DataStage is not properly invoking the SQLForeignKeys() function (through the BCI). You will need to involve your official support provider with this one. Meanwhile you could try importing the table definition without importing its relat...