metropia
asked on
getting warning: attempted to divide by zero
Hi,
I would like to get help in adding a check to the formula down below that takes care of the divide by zero error, if possible.
Thank you
I would like to get help in adding a check to the formula down below that takes care of the divide by zero error, if possible.
IIf(CDec(Sum(IIf(Fields!OrderLineStatus.Value = "OPEN", Fields!OrderBalanceQty.Value, CDec(0)))) <> 0, (CDec(Sum(IIf(Fields!OrderLineStatus.Value = "OPEN", (Fields!OrderBalanceQty.Value * Fields!OrderPrice.Value), CDec(0)))) / CDec(Sum(IIf(Fields!OrderLineStatus.Value = "OPEN", Fields!OrderBalanceQty.Value, CDec(0))))), 0)
Thank you
You can check it before division using expression.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ValentinoV: I've never used ISERROR in SSRS, but I saw it referenced in a couple of SSRS forums (like http://social.msdn.microsoft.com/forums/en-US/sqlreportingservices/thread/ca1f9bad-8f7a-44c5-8c8b-9739e433cbfd) and I've used it extensively in Excel - I should have confirmed it before assuming it worked.
My mistake - glad your solution did the trick!
My mistake - glad your solution did the trick!
After ryanmccauley's last comment I got curious and started to investigate a little. IFERROR (as Ryan mentioned in his first comment) doesn't exist but ISERROR is indeed an existing VB function. However, it will only work in case of an exception. Here's its description:
"Returns a Boolean value indicating whether an expression is an exception type."
So I decided to give the following a try: IsError(1/0)
And that returned False. Erm, did I miss something? Apparently I did.
Then I put the following in a textbox: =1/0
Guess what? That actually runs without any errors! And it will produce the string "Infinity".
Alright, what about the following: =IsError(1.1/"duh")
That will produce #Error on the report and the following rsRuntimeErrorInExpression in the Output pane: Input string was not in a correct format. (I admit I'm taking it a bit far there but from a function as IsError I'd expect if to "handle" the exception.)
To be honest, so far I haven't succeeded in getting a True out of the IsError function. So I decided to not use it.
Another thing which I've discovered is that the expression result behavior is not consistent over different data types. The "Infinity" above should already ring a bell. Surely I remember situations where I'd actually gotten a "division by zero" error? And also, if my memory would be failing, why are there so many references to issues with it on the internet?
Let's move to the next step of the investigation. If 1/0 doesn't generate a "div by zero" error, doesn't that mean that the following should work?
=IIF(Fields!Number2.Value = 0, "divzero", Fields!Number1.Value / Fields!Number2.Value)
Well, apparently it does work! But not in all situations. And that's where my confusion comes from. There's actually a hidden gem in the following Brian Welcker blog post: End of Amnesia (Avoiding Divide By Zero Errors)
If you read his article you'd think that it confirms what I explained earlier. And it does. But there's a hidden condition in the second paragraph:
"This works fine unless a value in the Cost field is zero (and is not an integer or double), in which case you will get '#error' displayed in your report. This is because a divide by zero with a decimal field will throw an exception."
In other words, the simple IIF(B = 0, "it's zero", A/B) will work fine as long as the data type of A and B is not decimal. But if they are decimal, you'll start seeing #Error in your report and the "Attempted to divide by zero" rsRuntimeErrorInExpression in the Output pane.
Why this behavior difference occurs isn't yet 100% clear to me but it must be either related to how VB has implemented the / operator for the different data types OR to how the report processing engine handles different exceptions. There must be some code somewhere that decides to display "Infinity" instead of generating an error.
I hope you found reading this as interesting as much as I learned from the research.
Have fun!
Valentino.
"Returns a Boolean value indicating whether an expression is an exception type."
So I decided to give the following a try: IsError(1/0)
And that returned False. Erm, did I miss something? Apparently I did.
Then I put the following in a textbox: =1/0
Guess what? That actually runs without any errors! And it will produce the string "Infinity".
Alright, what about the following: =IsError(1.1/"duh")
That will produce #Error on the report and the following rsRuntimeErrorInExpression
To be honest, so far I haven't succeeded in getting a True out of the IsError function. So I decided to not use it.
Another thing which I've discovered is that the expression result behavior is not consistent over different data types. The "Infinity" above should already ring a bell. Surely I remember situations where I'd actually gotten a "division by zero" error? And also, if my memory would be failing, why are there so many references to issues with it on the internet?
Let's move to the next step of the investigation. If 1/0 doesn't generate a "div by zero" error, doesn't that mean that the following should work?
=IIF(Fields!Number2.Value = 0, "divzero", Fields!Number1.Value / Fields!Number2.Value)
Well, apparently it does work! But not in all situations. And that's where my confusion comes from. There's actually a hidden gem in the following Brian Welcker blog post: End of Amnesia (Avoiding Divide By Zero Errors)
If you read his article you'd think that it confirms what I explained earlier. And it does. But there's a hidden condition in the second paragraph:
"This works fine unless a value in the Cost field is zero (and is not an integer or double), in which case you will get '#error' displayed in your report. This is because a divide by zero with a decimal field will throw an exception."
In other words, the simple IIF(B = 0, "it's zero", A/B) will work fine as long as the data type of A and B is not decimal. But if they are decimal, you'll start seeing #Error in your report and the "Attempted to divide by zero" rsRuntimeErrorInExpression
Why this behavior difference occurs isn't yet 100% clear to me but it must be either related to how VB has implemented the / operator for the different data types OR to how the report processing engine handles different exceptions. There must be some code somewhere that decides to display "Infinity" instead of generating an error.
I hope you found reading this as interesting as much as I learned from the research.
Have fun!
Valentino.
Alternatively, you could use the little known IFERROR() function to replace your error with a suitable value:
Open in new window
And it would give you a zero value if the expression causes a calculation error (in this case, divide by zero).