Error persisting business object

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
Post Reply
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Error persisting business object

Post by nlarson »

Another error I just started recieving:

Internal error. Error persisting business object Metrics Data truncation: Out of range value for column 'Current' at row 1

This is a numeric field with no value range and # as the format, to round any calculation to a whole number. The attribute is updated through a multiplication of two other numeric fields so I don't understand how there could be an out or range value.

Any ideas?
aware_support
Posts: 7526
Joined: Sun Apr 24, 2005 12:36 am
Contact:

Post by aware_support »

Multiplication must be producing a huge value that is out of range for the column. If the format of the numeric value is #, the type will be integer. You can try changing the format to #.0 which will produce a double value with a much bigger range than integer
Aware IM Support Team
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Post by nlarson »

The logs indicate the BO updates then the process fails.

The rule is Metrics.Current=Metrics.ResultsToDate/Metrics.ExpecteToDate*100

The Values in this case are 30/30*100=100

But if I delete this simple rule, all is well.

Any other ideas?
aware_support
Posts: 7526
Joined: Sun Apr 24, 2005 12:36 am
Contact:

Post by aware_support »

Are you dividing two dates? This is not supported
Aware IM Support Team
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Post by nlarson »

No... 'To Date' means, up till now... I'm dividing 2 integers. I think I was pretty clear saying the value was 30/30...
tford
Posts: 4238
Joined: Sat Mar 10, 2007 6:44 pm

Post by tford »

I would add parenthesis:

Metrics.Current=(Metrics.ResultsToDate/Metrics.ExpecteToDate)*100
Tom - V8.8 build 3137 - MySql / PostGres
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Post by nlarson »

the system removes the parenthesis
:cry:

Thanks though.
tford
Posts: 4238
Joined: Sat Mar 10, 2007 6:44 pm

Post by tford »

What do the logs say about this calculation? I don't mean the error message.
Tom - V8.8 build 3137 - MySql / PostGres
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Post by nlarson »

Ok, looks like I might have missed something in the logs, past the correct calculation there is a value of 'Current=9223372036854775807'.

Obviously there is some funky math, but the rules are so simple I just can't figure out were. The process which triggers this has not been changed in ages but have changed some values from decimal to whole number so that has to be the problem.

I need some sleep, but back at it in the morning. Think I'll be getting a support ticket, lol.
nlarson
Posts: 597
Joined: Thu Apr 14, 2011 7:56 pm

Post by nlarson »

I still don't know where the root cause is, I was able to work around this by inserting an if condition to prevent the rule from firing if the divisor was =zero. I'll get down into the weeds to find the root if I get some time.

Thanks for the help guys!
hpl123
Posts: 2607
Joined: Fri Feb 01, 2013 1:13 pm
Location: Scandinavia

Re:

Post by hpl123 »

aware_support wrote: Tue Sep 06, 2011 10:53 pm Multiplication must be producing a huge value that is out of range for the column. If the format of the numeric value is #, the type will be integer. You can try changing the format to #.0 which will produce a double value with a much bigger range than integer
Good tip, I got a similar error today: "Internal error. Error persisting business object PCard truncation: Out of range value for column 'TId' at row 1" and I changed the format to #.0 (it was # per default for a number attribute) and then the error went away.

NB: This fix also create some issues so be aware and test thoroughly if you use this fix. In my case, the issues were related to the formatting of the number being saved and used differently in certain places in this app e.g before it was 12345 and after the format fix it was 12345.0 and also in some cases this got turned into 12345.234 (the additional numbers .234 got added as part of another separate process/function) and that number was then used in various places to check against other BO instances which caused issues (12345 <> 12345.234). A bit of a mess and I have to backtrack and change this back actually :( and fix this in another way.
Henrik (V8 Developer Ed. - Windows)
Post Reply