Asok thanks for the response

I'm looking to store the long version. Both fields are defined in their
Tables as 2 decimals, and I tried the following already:

Dec(String(Part-Routing.Weight-Per-Unit,">>,>>>,>9.99999"))
Round(Part-Routing.Weight-Per-Unit,5)
Truncate(Part-Routing.Weight-Per-Unit,5)

each time it stored a value of .04265 as .04

I guess I was looking for some way to disable the Field format in the DB.
The ERP system is able to do it somehow as 5 decimals, in both tables. I
guess I can suck it up and ask the developers how they did it. The answer
might be in some kind of a trigger as you suggest.

Of course I could also give them some grief for not formatting the fields to
5 decimals.

Either way, if I find an answer I'll post it here.

Best Regards,

Rob W

"Asok the Intern" <asok@inatek.com> wrote in message
newsUs_d.22104$hU7.10198@newssvr33.news.prodigy. com...
> If you look in the data dictionary at these two fields, what value is in
> the "Decimals:" field for each? This value dictates what data will be
> stored in the database. If the po-receiving-history.weight-per-unit
> format mask is set to ">>,>>>,>>9.99<<<<" and the decimals field is set to
> 2, only .99 will be stored to the right of the decimal point...period.
>
> From your message, I am not sure if you want to store the long or the
> short version of the value, so I will try to explain both:
>
> You want to store the long value in po-receiving-history:
> Keep in mind that the mask is just the default display. You can store and
> display whatever you want as long as it does not conflict with the
> decimals field. In the case of the part-routing table, it is natural and
> expected for the stored value to be 0.04265 if it does not violate the
> decimals field. The << and >> in the format will suppress leading and
> trailing zeros stored in the field. I assume that your database has the
> field po-receiving-history.weight-per-unit defined with a decimal value of
> "2," so the database will truncate it to 2 places.
>
> You want to store the short value in part-routing:
> Something quick and dirty like this should do the trick...
> FOR EACH part-routing
> EXCLUSIVE-LOCK:
> ASSIGN
> part-routing.weight-per-unit =
> DEC(STRING(part-routing.weight-per-unit, ">>,>>>,>>9.99")).
> END.
> Of course, you will want some WHERE clause to limit the impact, but that
> will get the values back to two decimal places of significance.
>
> Does your ERP app have any type of user defined set-up params such as a
> number of sig digits in the decimal portion? I have seen a few packages
> that use a format function and/or trigger system to multiply/divide by a
> large value to retain a customer specified number of digits. It adds a
> lot of overhead, but it will at least give you the data you are looking
> for.
>
> Hope this ramble was of some help,
>
> Jeff Zimmerman
> CMSG (Code Monkey in Search of a Gig)
> Akron, OH
>
>
> RobW_Progress wrote:
>> I've looked thru everything I could see at progress.com and peg.com, so
>> I've come her looking for help.
>>
>> We have a Weight-Per-Unit field defined as DECIMAL with a FORMAT
>> ">>,>>>,>>9.99<<<<".
>>
>> I am performing a po-receiving-history.weight-per-unit =
>> part-routing.weight-per-unit.
>> The weight in the part-routing table is stored as 0.04265, even though
>> it's table format was defined as ">>,>>>,>>9.99<<<<". When I perform the
>> command, the po-receiving-history.weight-per-unit is stored as 0.04.
>>
>> How can I override this format? I've tried ROUND, TRUNCATE to no avail.
>> The table format controls how this field is storing the data.
>>
>> Also, I cannot redefine the format, as this is an ERP package and I have
>> no access to the source code. I'm just trying to clean up some data,
>> which I need to do on occasion.
>>
>> Thanks for any help on this subject - I've run out of ideas.
>>
>> Rob Willoughby
>> IT Manager
>> Madison Heights, MI
>>