SEO

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

"RobW_Progress" <robw@Hltool.com> wrote in message
news:jLydnSxY_OGCL6TfRVn-gQ@giganews.com...
> 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
>
>
Maybe this sounds kind of odd, but is the mask correct?
">>,>>>,>>9.99<<<<" ????? Have you tried ">>,>>>,>>9.99>>>>"?

JP

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
>
>

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
>>

Is there by any chance a field called Num-of-decimals (or something like
that) defined as an integer for either of those records? If so, they
are most likely using some flavor of multiply/divide by
10^num-of-decimals to store the value. Worth a look.

Jeff Zimmerman

RobW_Progress wrote:
> 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
>