Hi,
I just want to inform you that I got a Hot-Fix for this from BMC, and it seems
to work :-)
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.
> 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:[email protected]] On Behalf Of Bade, Yogesh
> Sent: 11 January 2013 07:27
> To: [email protected]
> 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:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: Thursday, January 10, 2013 4:02 PM
> To: [email protected]
> 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:[email protected]] On Behalf Of Misi Mladoniczky
>> Sent: Wednesday, January 09, 2013 3:10 PM
>> To: [email protected]
>> 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:[email protected]] On Behalf Of Misi Mladoniczky
>>> Sent: Wednesday, January 09, 2013 10:03 AM
>>> To: [email protected]
>>> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
