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?
Absence of distribution key in the design schema
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 152
- Joined: Mon Mar 07, 2011 6:16 am
-
- Participant
- Posts: 152
- Joined: Mon Mar 07, 2011 6:16 am
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?
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?
Soumya
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.
As noted previously, I suggest starting there before you head down the other rabbit hole.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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.
Choose a job you love, and you will never have to work a day in your life. - Confucius