Hi
My job is designed below:
Source (ODBC) --- LOOKUP --- TRASFORMAER -- FLATFILE (FIXED WIDTH).
Warning :
When binding output interface field "XXXX" to field "XXXX": Converting a nullable source to a non-nullable result;
I am using a view as a source.
1) If I make the field "XXXX" as Nullable Y, Then I will give me the warning at the Lookup Stage. At Lookup This field is not null.
2) If I make it NULL at lookup then it aborts the job. Because it is output from the lookup.
3) As target is SEQ file, XXXX field should be NULLABLE "NO"
4) I tried using CAST and NVL functions in the QUERY as well.
Can you please help me to remove this warning?
Thanks
Bob
Warning at Source
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
If your Lookup Failed rule is "Continue" then all fields on the reference input need to be nullable, as do any output fields derived from them. With "Continue" you are effectively doing a left outer join, with the reference input the right hand side of that join.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Hi Ray,
Thanks for the reply. The resolution that you have provided is working fine.
However I didn't understand if I define a field say "XXXX" as a KEY then how datastage allows us to make it NULLABLE. Because as per my understanding (Consider Primary Key) key should not containt null.
Can you please let me know how DS handles this concept?
Thanks for the reply. The resolution that you have provided is working fine.
However I didn't understand if I define a field say "XXXX" as a KEY then how datastage allows us to make it NULLABLE. Because as per my understanding (Consider Primary Key) key should not containt null.
Can you please let me know how DS handles this concept?
Thanks
bob
bob
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Your understanding that "Key" = "consider to be primary key" is the flaw. In this context "Key" means "join key", or common value used to identify the join. Neither in DataStage nor in SQL does the join key have to be a primary key.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.