DSXchange

As suggested earlier by experts it is best advised to split, however following could achieve the purpose. You could first identify the Inserts/Updates by doing a look-up,hence for your example EMPNO ENAME 7368 DEV (Insert) 7369 SMITH (Insert) 7369 SMITH (insert) Subsequently, within a transformer yo...

There could be more simpler & smarter solutions suggested further . One of the naive possibilities include 2-3 jobs. Counter Initialization based on keys could be 1 DS job or could be merged. Subsequently,have a single DS job which does this validation , sorted on ascending counter for the keys....

Thanks keshav on confirmation

At times there are ORCH_WORK_<hexvalue> tables left behind in the database. Is this <hex value> stored somewhere which could be used to identify the tables. Currently Information available: Possibly through the Director ORCH_WORK_<hexvalue> tables get auto dropped on re-execution of DS Jobs. Alterna...

We have faced similar problem whilst reading from TD API stage with date as datatype works erratically, hence char(10) is the safest option.

Has been posted in the forum quite a few times - Teradata API supports ANSI SQL. This error is seen to occur also if there are any charachters [ e.g, char(10), char(13) etc ]

What specific problem you are facing, since if using Teradata API stage and the normal method of mentioning 'USING <<column_name>> , followed by exec <<macro_name>> ( :column_name ).

Do please post any specific message / error you are facing.

Currently, no options are provided to change 'any' settings on orch_xxx tables within DS. Alternative is to create a seq file and then invoking a external mload script to insert into TD table , which will be faster, even after considering the I/O for creating a seq file for huge volumes of data. As ...

Currently, no options are provided to change 'any' settings on orch_xxx tables within DS. Alternative is to create a seq file and then invoking a external mload script to insert into TD table , which will be faster, even after considering the I/O for creating a seq file for huge volumes of data. As ...

following could be some pointers related :
check pls on the index and it's skewness whilst loading into table.[ can get in touch with DBA if required ]
any full row duplicate records exist
any index related duplicate records exist

Few options which could be tried { if not already } You could try breaking the job and having target as sequential file, with the combinable operators being disabled. Alternatively, could check on o/s whether there is another job already running when the various options were tried. Or as suggested c...

The following entry is mentioned in your log
---Teradata_Enterprise_0,0: Cannot write record.

Looks like ,check the metadata in Teradata and in the source dataset
would be good place to start.

The following entry is mentioned in your log
---Teradata_Enterprise_0,0: Cannot write record.

Looks like ,check n the metadata in Teradata and in the source dataset
would be good place to start.

Duplicate rows will never be captured in any database table.
Since teradata enterprise stage uses native teradata fastload utility which
has this feature.
At the most, field Conversion errors and Duplicate Index errors will be captured in the error tables which is zero as per your log.

I believe you are not using named pipes as a option on the utilities.
it is preferable that you also check 'Delete data file after load' option
on the utilities.

That way both the developers would be able to run their jobs one after another.