Implicit converison in Aggregate stage

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
reachmexyz
Premium Member
Premium Member
Posts: 296
Joined: Sun Nov 16, 2008 7:41 pm

Implicit converison in Aggregate stage

Post by reachmexyz »

Hello All

In a datastage job i am feeding a field named Net_Am (Decimal[38,10]) from sort stage to an aggregate stage. This stage will calculate the sum of the Net_Am field.
I fed this sum field to a new field called Sum_Net_Am with datatype
Decimal(39,12) in aggregator. When i run the ob i am getting the below error.

Aggregator_13: When checking operator: When binding output interface field "NET_WP_AM" to field "NET_WP_AM": Implicit conversion from source type "dfloat" to result type "decimal[39,12]": Possible range/precision limitation.

Where is this dfloat coming from?
girija
Participant
Posts: 89
Joined: Fri Mar 24, 2006 1:51 pm
Location: Hartford

Post by girija »

dfloat is the internal data type for decimal(38,10) same as BigInt (15) --> int64.
reachmexyz
Premium Member
Premium Member
Posts: 296
Joined: Sun Nov 16, 2008 7:41 pm

Re: Implicit converison in Aggregate stage

Post by reachmexyz »

reachmexyz wrote:Hello All

In a datastage job i am feeding a field named Net_Am (Decimal[38,10]) from sort stage to an aggregate stage. This stage will calculate the sum of the Net_Am field.
I fed this sum field to a new field called Sum_Net_Am with datatype
Decimal(39,12) in aggregator. When i run the ob i am getting the below error.

Aggregator_13: When checking operator: When binding output interface field "NET_WP_AM" to field "NET_WP_AM": Implicit conversion from source type "dfloat" to result type "decimal[39,12]": Possible range/precision limitation.

Where is this dfloat coming from?

Can anybody please tell me how can i avoid this?
girija
Participant
Posts: 89
Joined: Fri Mar 24, 2006 1:51 pm
Location: Hartford

Post by girija »

Why do you need decimal(39,12) ? I think decimal(38,10) is enough to hold the sum or count.
reachmexyz
Premium Member
Premium Member
Posts: 296
Joined: Sun Nov 16, 2008 7:41 pm

Post by reachmexyz »

girija wrote:Why do you need decimal(39,12) ? I think decimal(38,10) is enough to hold the sum or count.
Even if i put decimal(38,10), i am still getting the same error.
when i add two numbers like
99.99 with 99.99, result is 199.98.
Left part of the result decimal now increased to 3 while the source decimal is 2
girija
Participant
Posts: 89
Joined: Fri Mar 24, 2006 1:51 pm
Location: Hartford

Post by girija »

Make the column as double with no length and scale.
girija
Participant
Posts: 89
Joined: Fri Mar 24, 2006 1:51 pm
Location: Hartford

Post by girija »

99.99 + 99.99 = 199.98

What else do you expect? Did you any warning when you run your job?
Kryt0n
Participant
Posts: 584
Joined: Wed Jun 22, 2005 7:28 pm

Post by Kryt0n »

girija wrote:99.99 + 99.99 = 199.98

What else do you expect? Did you any warning when you run your job?
Somehow suspect he stated that in response to your "38,10 should be enough" comment...

Anyway, in answer to the issue, in the aggregator properties, under aggregations, select "Default To Decimal Output" and set to 39,12... or 38,10 or whatever else you want...
AndreiMK
Participant
Posts: 2
Joined: Thu Aug 04, 2011 5:33 am

Post by AndreiMK »

Kryt0n wrote:Anyway, in answer to the issue, in the aggregator properties, under aggregations, select "Default To Decimal Output" and set to 39,12... or 38,10 or whatever else you want...
Thanks Kryt0n, it is only you who has fully paid attention to the question itself and has answered it clearly :)
Post Reply