Are there any guidleines for using the Netezza connector directly as a lookup? I'm getting a variety of errors ;
- columns not being right type
- columns not found , even though they're right there
Is it recommended to have a stage (copy, dataset) between the Lookup stage and the Connector stage?
I need to do some manipulation on one of the key columns in the database data, so having the connector stage generate the SQL will not work.
Using a (green) DB2 connector stage, we did not have these problems
Any suggestions welcome.
Using Netezza connector as lookup
Moderators: chulett, rschirm, roy
Don't know how many Netezza users we have here, or how many of them have done lookups directly to the connector. While you wait to see if anyone that matches that criteria wanders by, perhaps opening a support case would be a good idea. Unless you've already done that, of course.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 8
- Joined: Mon Mar 11, 2013 2:51 pm
- Location: RTP, North Carolina
Re: Using Netezza connector as lookup
I've done this in that past, and didn't run into the issues that you're having.
But it sounds like the NZ connector is throwing warnings on column and column type mismatches between your select statement and the output columns that you have defined.
How are you selectingdata from your Netezza connector?
What columns do you have defined in the output link of the NZ connector?
In my experience, SQL select statements from NZ require you to cast the output to the correct data type of the target DS column, especially if you are doing manipulation within the SQL select statement itself.
But it sounds like the NZ connector is throwing warnings on column and column type mismatches between your select statement and the output columns that you have defined.
How are you selectingdata from your Netezza connector?
What columns do you have defined in the output link of the NZ connector?
In my experience, SQL select statements from NZ require you to cast the output to the correct data type of the target DS column, especially if you are doing manipulation within the SQL select statement itself.
Thanks guys,
I tripled-checked the job, and it was indeed type mismatches. I can use the connector directly against the lookup stage - no intermediate stage required.
However, with server jobs, I've found I had to insert a hash file stage between the connector & transform, so that's why I was thinking the same effort was needed for Px jobs.
I tripled-checked the job, and it was indeed type mismatches. I can use the connector directly against the lookup stage - no intermediate stage required.
However, with server jobs, I've found I had to insert a hash file stage between the connector & transform, so that's why I was thinking the same effort was needed for Px jobs.
Nope, that's just one of the architectural differences between the two job types. And for the record, in a Server job you do not have to use a hashed file for the lookup target (direct to a relational source can be done, for example, and basically equates to a sparse lookup from what I recall) but the hashed file approach is the accepted standard.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers