DSXchange

I have a simple parallel job with the below design:

Dataset--------->copy--------->DB2 connector(running in partition type as DB2 connector)

In the above design in the DB2 connector I'm updating a table(Assuming T1).Now T1 is hash partitioned(DPF in DB2) on the basis of C1 in the DB2 level. Now I'm updating T1 (C2,C3) on the basis of C4.


The job is aborting with the following message in one environment:

Unable to locate a schema field that can be associated with column C1. This field must be present in the schema, because this column belongs to the partitioning key, which must be obtained for the partitioning algorithm to function. (CC_DB2Partitioner::initPartKeyObjects, file CC_DB2Partitioner.cpp, line 687)


But the same job ran fine in the different environment.


Please note that in the different datastage environment it's point to different database server.

In the first environment it seems that it was not able to get the DB partition details without the distribution key in the schema

Is it happenig due to Datastage or database?

Database. Check the permissions associated with the connection user in that environment, also the structure of the target. Compare them to the environment where things worked.

That's where I'd start.

Thanks a lot Craig for your response. I will check it from the database level.meanwhile I have checked the below link from IBM:

http://www-01.ibm.com/support/knowledge ... 0371E.html

It's stating that partition column should be there in the design schema or else the job will abort. That is the normal behavior which is happening in one of the environment.

Now the thing is in the other environment how it's running fine?

Obviously something is different between the two environments. Unless you have doubts as to your promotion process then the primary difference is the database you are connecting to which I why I suggested starting there. I can't tell you how many times over the years that while working my way up the food chain from dev to prod that a table hasn't been identical at some point up the ladder. Some times the differences don't matter all that much and sometimes they do.

As noted previously, I suggest starting there before you head down the other rabbit hole.

Perhaps DB2 privileges are different? Either way, you could also do additional testing to narrow it down, such as carefully testing a test job against a prod database, and/or carefully testing a prod job against a test database.