I have defined a data connection (I am not using associated parameter sets, I just enter the connection details in the connector properties directly) and use this in a Netezza Connector. The job runs fine.
I then modified the connection details in the data connection object, specifically the database name to point my job to a different database, recompile successfully, but when I run or validate the job I get the following error from the connector stage:
Internal error occured (CC_NZMetadataHelper::reconcileOutputLinkSchema, file CC_NZMetadataHelper.cpp, line 1.041)
Does anyone know what this means and why I'm getting the error?
Thanks in advance.
This topic has been locked.
3 replies Latest Post - 2013-01-22T12:28:52Z by SystemAdmin
Pinned topic Changing a data connection object
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-22T12:28:52Z at 2013-01-22T12:28:52Z by SystemAdmin
Re: Changing a data connection object2013-01-18T09:25:10Z in response to SystemAdminHere's some additional information:
When I open the connector and make a trivial change to the SQL that is executed (e.g. adding some extra white space in the SELECT) save and compile, the job works again.
I have also looked at the OSH script generated after the change in the connector object and the recompilation and the XML where the database connection information is stored is the same (I'm referring to the <Connection> ... </Connection> XML segment).
The OSH script for the job version that does not work does have some additional XML though (as far as I can tell by doing a diff, this is the only difference) which is the following:
Can anyone provide some information that will help me understand this behavior, why I'm getting the error and whether datastage works as expected or if this is a bug?
WalkerDean 270000WM0028 Posts
Re: Changing a data connection object2013-01-22T12:28:52Z in response to WalkerDeanThank you for the response. 8.5 Fix Pack 3 which includes APAR JR42412 has been applied to the environment where I experience this behavior. I guess I will have to take this up with support.