DSXchange

Assuming this to be true, Do you mean both duplicates tried to insert at the same time ? How did Hash Partition resolve this then ?

When I changed the partitioning to Hash, hash keys were same as the update keys used in the query, the error went away.

This is strange. The partitioning was Auto previosuly and the job used to work fine. Can this be explained?

I am trying to load DB2 table in Upsert method. Updates are happening first and then Inserts. I am getting the error INDEX1 RESTRICTS COLUMNS WITH SAME VALUES. TABLE NAME But if it is Update Then Insert then why is this issue happening? Even if there are duplicates in my source, the problem should h...

Looks like, I need to go for trial and error here. Not sure, is there any other way to calculate exactly what should I mention in the Insert Array Size

Dropped it to 1, it worked....too slow although...is this the only way ?

ray.wurlod wrote:How big (in bytes) are your rows?

Is the product of array size and row size too large to fit in memory? ...

Array Size specified in Target is 2000. As for the Row Size, since this is a delete operation, The metadata of the target only has the key column. the Mode is Upsert/Delete Only

chulett wrote:Try hash partitioning on the key field(s) used in the upsert. ...

Same Result even after Hash Partitioning. SIGSEGV error on target ODBC.
I have disabled Operator combination

priyadharsini wrote:what is the partition defined on ODBC stage?

Auto

When a SIGSEGV error goes away when we change the configuration file from multiple node to single node, does this mean that the Partitioning is the culprit in this case. I have a job which fetches from ODBC and inserts into ODBC stage. The mode is Upsert(Update Then Insert). The job fails with SIGSE...

If you have a sequential file, which is storing your rejects, then DataStage will always add leading zeroes to decimal values. You may need to have a transformer before the column export stage and then convert the decimal value input into string and pass on the output as Varchar data type. The funct...

There's no such thing as junk characters. They are your client's data. If they're in the source database, they're valid, and you have to move them. First step is to find out what they actually are. ... Source Database is different from target. Is that the reason ? Source is SQL Server, Target is DB2

I have a job where data is being fetched from SQL Server DB and populated into DB2 target. The target is truncated and written every time. I am using ODBC stage in the job(Source as well as target). There are two columns in the source table each of Varchar(8000). These columns are also present in ta...

Whats the structure of your job?

Changed the Partitioning in target ODBC to Same. It was hash before. And the warning went away. Still not sure what caused this in the first place. Anyway the issue is resloved now

tanaya.deshpande@tieto.co wrote:I am getting this error for any query type...

Check the query inside the stage. The WHERE condition seems to be incomplete. Try running the query directly on database and verify that rows are being returned. Then run the DS job