DSXchange

Are you perhaps using customized code values and have chosen the same code value for two different diff cases?

Search for "surrogate key" and "type 2 slowly changing dimension". This is the conventionally used technology in this case. Only one of the dimension records is current at any one time for each particular business key value.

... and you'll find your duplicate post - please delete it before anyone replies to it.

This error (abort) has occurred because your "Lookup Failed" rule is set to "Fail". Reference rows are not consumed by a Lookup stage so there is no way, using this stage, to determine which keys were touched. Use a Merge stage instead if you need this functionality.

How about setting the APT_RDBMS_COMMIT_ROWS environment variable?

That's because Oracle reports all integers as NUMBER(38). The job may still work OK, and changing the data type in the job to Integer may help too. Better would be to change the data type in the imported table definition before loading the table definition into the job. In that case, create a messag...

A sequencer makes an any or all decision, and you probably need one. But the thing you use it IN is called a "job sequence", not a sequencer.

Write a sequence of numbers as keys to a hashed file (UniVerse table) on the conductor node, then read it back. The hashing algorithm will give you some measure of scrambling, and your generated sequence will be unique. You could use an External Target stage or a server job shared container containi...

You could always take a training class

There is a "UniVerse" command called ENVIRONMENT (or just ENV) which returns a list of all current (set) environment variables. You could invoke this through DSExecute.

I once waited more than 24 hours for the list of tables to be returned from DB2/400 (on AS/400 machine). On this platform, every file in the operating system is reported as a table. Soon learned to always specify a filter! And that was just configuring the ODBC driver.

IF you have been systematic about managing your metadata, and only ever loaded the table definition into these jobs from the Repository, then your answer is as simple as choosing that table definition in Manager and requesting a Usage Analysis (the beaker-shaped tool on the Toolbar).

Supply and demand again. Manage your expectations. Try splitting the 19 lookups across, say, four transformer stages rather than have one as the bottleneck. Next time you run the job, enable statistics on the Job Run Options dialog for that single transformer stage - learn where it is spending most ...

Surely, if the error is "unable to extend tablespace", then the issue is with the DBA to change the auto-growth characteristics (or even the actual size) of the tablespace in question?