TJoin and TMap and BigDecimal with a precision specified

[Anonymous]

Dear Forum and Talend,
I was wondering if anyone had ever come across a problem with using TJoin or TMap to join result sets where one of the join columns is a BigDecimal with a precision specified (e.g. in Oracle tha columns is defined as number(14,4) )
Both TJoin and TMap seem to not match on this type of column .. i.e. some of the rows which do actually match come through the non matching result set ...
???
Has anyone else seen this or encountered this? or have a solution to this?
thanks, Allan.

[jkrfs]

I switched it back to FLOAT and it works fine, but I am curious if this is a bug? Why can I not compare two BigDecimals in a tMap?

[alevy]

Using BigDecimals for the lookup key works fine for me in v4.1.3 even if the two columns have different length and precision...

[jkrfs]

Weird, I am using 4.2M4.

[alevy]

You should never use Milestone releases other than for beta-testing given the potential for outstanding bugs. I strongly suggest you urgently upgrade to v4.2.2 and try again.

[jkrfs]

I got this before 4.2.2 was released, I'll upgrade now.

[alevy]

I just encountered this problem using v4.1.3. It's caused by the scale (i.e. precision i.e. decimal places) of the BigDecimal amounts. If I force the two amounts to have the same scale, even if no rounding is required, then the lookup works. I no longer have the test I used for my post on 29 June but I doubt I had main and lookup with different scale. I've submitted a bug.

[jkrfs]

I forced both of them to have the same scale, but of course this is to the 8th place (which is what we use in our DB), perhaps I need to cut it down to 3 places to enforce the matches. Another weird thing is that both amounts when I was testing this was .0 all the way, maybe I'm wrong.

[alevy]

BigDecimals don't lose accuracy like floating-point variables do so they should match correctly if each side has the same number of places. Remember that the actual scale of the Java variable is not necessarily (even unlikely to be) the same as the schema precision. Did you use .setScale to force the scale? You can see the exact scale by printing it (System.out.print) or use .scale() to get the number.