Recently I was in fight with an ORACLE “issue” I found in my day-by-day coding activity. I was lucky to discover this “issue”, after 2 hours spent in debugging, rewriting mappings, and some bad words I said to my computer, I found a solution and a post which was helpful for me.
The situation: I was mapping a simple, usual, set of Entity Properties to a related set of ORACLE NUMBER columns with no precision info. These columns were updated by a Package Procedure. So, assuming Column1 and Column2 were the comlumns I was trying to map, I mapped them in a standard way as:
1: <!-- ... -->
2: <property name="PropertyOne"
3: type="System.Decimal">
4: <column name="COLUMN1"/>
5: </property>
6: <property name="PropertyTwo"
7: type="System.Decimal">
8: <column name="COLUMN2"/>
9: </property>
10: <!-- ... -->
I though this could be a very easy and standard mapping, so I didnt takeĀ so much care about, because this was a usual mapping, but I was wrong (maybe I wasn’t but Oracle were)
The problem: After I’ve done with the mapping above, I experimented a strange kind of Exception, this Exception was so strange I fall in a desperate search of all possible causes, but with no asnwers. The Exception was “Arithmetic operation resulted in an overflow“.
Now, no spending more words about my search for a cause, This situation makes me crazy, what could be the problem I asked to me? Then, as a last try, I’ve done the same operation I was doing with NHibernate in the old ADO.NET – DataSet way, and here the surprise: I FOUND THE SAME ERROR!! How was it possible, a column of NUMBER, with no precision (this assume the biggest precision supported, I though) fall in an Exception during reading from?
So after some search in the Google universe, I found a possible solution, and when I read about, it makes me too much crazy than before. I found a post in the Oracle Forum which describe a similar situation with the same exception, the answer says something like:
..We found that this is caused by a return value that has more places to the right of the decimal point than .NET can handle…Be careful of functions that return calculated values. They somethimes try to return a larger number than even ODP.NET can handle.
The solution: After days, I found this a ridiculous thing, why this could happen? Trying to better explain what above sayd, the problem was with CALCULATED VALUES maybe some times a calculated decimal can result in a decimal point number too bigger than a standard .NET decimal point number, so, it’s clear that I felt in this kind of exception, and NHibernate was innocent, because the underlying ODP.NET was the problem. I don’t want to spend much words, (I wrote more than I’ll wish), following the suggestion, this kind of bug could be solved in no many ways:
-
change the mapping to use with a VIEW with truncated values, but I don’t like to intriduce more objects than it’s needed
-
change the mapping to truncate values, but this fall into a “broken mapping”, a mapping which target to a single Database implementation, in my case Oracle
-
change the procedure to outputs a well delimitedĀ NUMBER value, but this wasn’t possible because this part of the application wasn’t written and controlled by me
So I decided for second way, in this way, just change the mapping as I will show, my code and my mapping go ahead without exceptions and any kind of problem, here is the modified mapping:
1: <!-- ... -->
2: <property name="PropertyOne"
3: type="Decimal"
4: formula="TRUNC(COLUMN1, 6)" />
5: <property name="PropertyTwo"
6: type="Decimal"
7: formula="TRUNC(COLUMN2, 6)" />
8: <!-- ... -->
In this way the resulting query result with the TRUNC function which applied as above truncate the decimal places as a desired, fixed number.
I hope this helps and could prevent anyone to a “crazy-noon” as does! ah… here is the Oracle Forum Post which gracefully helps me Arithmetic opreation…POST
Sorry for my poor and bad English, I hope I will learn well..Ciao!
April 14, 2009 at 20:13
Thank you!
This was very helpful.
Greetings.
Eivar.
May 10, 2010 at 09:56
Isn’t more simple to use:
May 10, 2010 at 09:56
Isn’t more simple to use:
property name=”PropertyOne” type=”Decimal(10,0)”
May 10, 2010 at 10:07
No. First of all I think this issue is resolved in the new oracle release, this article is related to an issue I gave 3 yrs ago.. but, to talk about, your solution is not correct because the issue was generated by the underlying oracle system, so specifying a precision as you suggest is not enough, because the issu is at a lower level, when the data type is read. So the only way to avoid this issue was to apply a TRUNC which apply a data trunc.