I am getting the following warning message while converting from Decimal[31,11] to Decimal[15,2]
Source_Mdf: When checking operator: When binding output schema variable "outRec": When binding output interface field "source_column" to field "target_column": Conversion from source type "decimal[31,11]" to result type "decimal[15,6]": Possible range limitation.
You have to get this alert, since what you are doing could result in loss of infomation. You can not shoehorn a 31 digit number into a 15 digit number. Therefore DataStage will not let you suppress generation of this warning.
In short, NO.
I take it [15,6] or [15,2] is a typographical/transcription error.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
ray.wurlod wrote:You have to get this alert, since what you are doing could result in loss of infomation. You can not shoehorn a 31 digit number into a 15 digit number. Therefore DataStage will not let you suppress ...
I am doing this conversion as part of migration from DB2 to Oracle. In DB2 the field was defined as [15,6] while in Oracle, it is defined as [ 31,11] for the same field.
What is the purpose of Decimal_From_Decimal function? Is it only to convert from Lower to Higher precision? I just want to avoid these warnings wherever possible.
Because your question forbade the use of message handlers, you have no choice - you have no way to stop DataStage from generating this message. Live with it. Or consider a message handler.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
if ur coversion is about just change in length...u dont have to use modify stage...just in any of the transformer stage you may be having in ur job...simply map Decimal[31,11] column to Decimal[15,2] column..u wont get any error or warning..
word of caution, if ur input value is really occupying all the bytes in [31,11]..you may come across data truncation, while converting to [15,2]
Historical Notes
Ur was a city in ancient Babylon. It has no place in DataStage documentation, which includes posts on this forum.
U was the first name of a UN Secretary General (U Thant, since deceased, so unlikely to be doing anything at all with DataStage).
Grammatical Note
"wont" is a noun. "won't" is the abbreviated form of "will not".
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
talk2shaanc wrote:if ur coversion is about just change in length...u dont have to use modify stage...just in any of the transformer stage you may be having in ur job...simply map Decimal[31,11] column to Decimal[15,2] column..u wont get any error or warning..
word of caution, if ur input value is really occupying all the bytes in [31,11]..you may come across data truncation, while converting to [15,2]
So I'm interpreting it that you cannot avoid warnings using modifier.
ray.wurlod wrote:Historical Notes
Ur was a city in ancient Babylon. It has no place in DataStage documentation, which includes posts on this forum.
U was the first name of a UN Secretary General (U Thant, since deceased, so unlikely to be doing anything at all with DataStage).
Grammatical Note
"wont" is a noun. "won't" is the abbreviated form of "will not".
I dont care abt hw n wat i write, in posts or sms or any personal mails or on messanger..I use abbr to make it fast & its simple enough for anyone to understand..my motive "msg shd be clear"
talk2shaanc wrote:I dont care abt hw n wat i write, in posts or sms or any personal mails or on messanger..I use abbr to make it fast & its simple enough for anyone to understand..my motive "msg shd be clear"
Not everyone here has English as a first, or even second language. Your shortcuts make it more difficult for them. Please desist. Because your message is NOT always clear.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.