DSXchange

Hi,

I've a monetary field defined as Numeric (30, 6). Data contained in table while readin by DS gets truncated to 14/15th digits.

<table>
<tr>
<td>File Value <td>Read/Written Value
<tr>
<td>==================== <td>====================
<tr><td>2345678910111213.999999 <td>2345678910111210
<tr><td>23456767767768768768 <td>23456767767768800000
<tr><td>23435743579403759075043 <td>23435743579403800000000
</table>

Any solution to this.[quote][/quote]

This is Answer to Question.
Try converting data feild from NUMERIC to TO CHAR using user defined SQL.

If you need specific solution?, need more information.

Look at the uvconfig file in your $DSHOME directory, your EXACTNUMERIC value is probably set to 14. Search the forum for the correct procedure to change this setting if you wish, or use strings as suggested above.

Need to send this numeric field for aggregation (Sum). Cannot use other data types like char fields.

This must be bcos of some limitation. IS it so ?

I know this is a silly question - but did you read my post? It does answer your question.

Thankx friend very much for the suggestion.

EXACTNUMERIC was set to 38 immediately after the installation as suggested by my friends.

Is there any limitation which is causing the problem.

FYI.

smat -d shows EXACTNUMERIC as 38.

Still the problem persists. DS 7.5 in installed on Win XP. I have searched all DS forums, but couldn't find any satisfactory answer and cause.

Pls advice ?

Let me understand. You have EXACTNUMERIC set to 38 in your uvconfig, the database table definition for a column is (30,6), you define the column as (30,6) in your database read stage (which stage, which database?) and when you output this column to a sequential file keeping the same (30,6) definition it rounds the number to an integer?

Ignore the aggregator for the moment. If this is the case, you have a reproduceable test case to submit to your support provider. If the above doesn't reproduce the problem, then the error must lie elsewhere.

You got it very right.

While trying to read even from a sequential file a number and writing to another sequential file, the same thing happens.

I shall escalate this to the support and see what they have to say on the same.

At least it is now a relatively easy thing for support to test and confirm. Please keep the thread updated with the result so that it is useful for future users of search.

I'm gathering similar evidences from my friends as well.

This seems to be a bug or else the changes in uvconfig have not been reflected properly.

Till then lets wait......

Yes, I keep this post alive.

DS 7.5 is now a thing of past for me. Theres no more issue with DS 8 about handling of big numbers.

Most of the products were never tested for such huge numbers, I reckon.

1. DS 7.5 had problem. Vanished with DS 8.
2. Informatica 7.1 PowerCenter too had the same problem.
3. Ab Initio - No idea, as such huge numbers were never dealt with.

Kind regards,
Abhijit

Yes, I keep this post alive.

DS 7.5 is now a thing of past for me. Theres no more issue with DS 8 about handling of big numbers.

Most of the products were never tested for such huge numbers, I reckon.

1. DS 7.5 had problem. Vanished with DS 8.
2. Informatica 7.1 PowerCenter too had the same problem.
3. Ab Initio - No idea, as such huge numbers were never dealt with.

Kind regards,
Abhijit

Yes, I keep this post alive.

DS 7.5 is now a thing of past for me. Theres no more issue with DS about handling of big numbers as we are onto DS8.

Most of the products were never tested for such huge numbers, I reckon.

1. DS 7.5 had problem. Vanished with DS 8.
2. Informatica 7.1 PowerCenter too had the same problem.
3. Ab Initio - No idea, as such huge numbers were never dealt with.

Kind regards,
Abhijit

The "problem" in DataStage server edition is not one of EXACTNUMERIC but one of PRECISION. The maximum PRECISION setting is 14 significant digits. I guess that stems from the fact that the technology was invented in the mid 1960s, when numbers that large simply did not occur in commercial data processing (8-bit or 16-bit operating systems and all that).