For reference the defect number is SW00445945.   If you do raise an issue with 
support please include this.

Mark

-----Original Message-----
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Bade, Yogesh
Sent: 11 January 2013 07:27
To: arslist@ARSLIST.ORG
Subject: Re: All DECIMAL and CURRENCY data has been corrupted in AR Server 
8.0.00

Hi,

This is a product defect where decimal input values are not handled correctly 
in some scenarios.
This specific to RHEL 6 and above and is due to changed behavior of strcpy() 
function on this OS version.
On previous releases of RedHat Linux this works fine.

This defect will be fixed by AR Server in a future patch on 8.0. If a hot-fix 
is needed please contact BMC support.

Regards,
Yogesh
-----Original Message-----
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
Sent: Thursday, January 10, 2013 4:02 PM
To: arslist@ARSLIST.ORG
Subject: Re: All DECIMAL and CURRENCY data has been corrupted in AR Server 
8.0.00

Hi,

Nothing seems to have changed. It also shows the same precision in MidTier
8.0.00 and in ARUser 7.6.04. This happens for all the DEC/CURR-fields in the 
system. I use these extensively, as it handles multi-currency-book-keeping.

The system has worked fine in many versions with very little change.

        Best Regards - Misi, RRR AB, http://rrr.se

> Have you checked to see if the Decimal still has the same Precision 
> between the 7.6.04 and the 8.0.0 ?
>
> Fred
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: Wednesday, January 09, 2013 3:10 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: All DECIMAL and CURRENCY data has been corrupted in AR 
> Server
> 8.0.00
>
> Hi,
>
> No, there is no workflow. Especially when I originally merged the data.
>
> This happened, and happens, to EVERY field (currency and decimal).
>
> Some data that did not have any decimal portion has been left intact. 
> But some of that data ha been changed anyway. I see no big pattern, 
> except that it seems to change the last digit to 5 or the last two to 55.
>
> For example 1350.00 was changed to 1350.05.
>
>         Best Regards - Misi, RRR AB, http://rrr.se
>
>> -----Original Message-----
>> Misi,
>>
>> This indeed sounds quite bizarre. And the only thing that I can think 
>> of, which I'm pretty sure you have as well and checked and crossed 
>> out - but just in case you haven't - is there a funky piece of 
>> workflow (AL's or F's) that manipulates the value to adjust that 
>> fraction by a tiny bit, just prior to the update or insert?
>>
>> Joe
>>
>> PS: How's the baby doing.. You got to post a pic of the RUG sweater 
>> that she got :-)
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList) 
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
>> Sent: Wednesday, January 09, 2013 10:03 AM
>> To: arslist@ARSLIST.ORG
>> Subject: All DECIMAL and CURRENCY data has been corrupted in AR 
>> Server
>> 8.0.00
>>
>> Hi,
>>
>> I am having serious trouble with my Linux AR Server 8.0.00 (patch002 
>> or unpatched), Linux, Oracle.
>>
>> All DECIMAL and CURRENCY data has been corrupted in the database. 
>> This has happened on ALL records which were merged into the new 
>> server. It also happens when you submit/modify any such fields with any 
>> client.
>>
>> I have attached a picture with the AR System Currency Ratios data, 
>> where the problem-server is to the left, and a correct 7.6.04 SP2 
>> Windows server to the right. The last two decimal places is wrong...
>>
>> With very small test with the included driver program, I changed a 
>> DECIMAL value and verified that the wrong value is written to the database.
>>
>> Driver: Set Entry on Decimal field
>> 0.864311
>>
>> ARAPILOGGING=88:
>> 0.864311
>>
>> SQL LOG:
>> UPDATE T7 SET C1504=.864355,C5='miz',C6=1357735821 WHERE C1 = 
>> '000000000040377'
>>
>> As you can see, the two last digits are stored as 55 instead of 11...
>>
>> I have tried this with many different clients and API-versions 
>> against the same server, which tells me that this is a server issue.
>>
>> If I access other servers with the same client, the value is stored 
>> as it is supposed to.
>>
>> I am running the server with se_SE.UTF-8 locale settings. This is not 
>> supposed to give any problem, but maybe it is realated...
>>
>> Any ideas?
>>
>>         Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> 2011)
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>
>
>
> ______________________________________________________________________
> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 
> "Where the Answers Are, and have been for 20 years"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers 
Are, and have been for 20 years"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers 
Are, and have been for 20 years"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to