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"
