SQL Server Reporting Services is a great tool that comes with SQL Server, and it is the tool I prefer to use when a report is needed.
I have built and continue to maintain many such reports, and once the reports are built, they don’t often need updating, unless the database schema changes or the customer’s requirements change. As a result, once they’re deployed, the reports don’t often require a lot of minding.
However, just as with any application, unforeseen events can cause the reports to fail. In my case today, bad data was allowed to be inserted into the database that was the source for one of my reports. The mechanism that inserted the data allowed the data in, but the code used to built the result set for the report threw an exception when it encountered the data. For security reasons, that exception was caught and a generic error appeared in the Web browser when attempting to run the report:
- An error has occurred during report processing.
- Query execution failed for data set <>
- For more information about this error navigate to the report server on the local server machine, or enable remote errors
- Query execution failed for data set <>
To find out what the source of the error was, I opened the report in the BI Development Server from SQL Server 2005. The data source was a stored procedure. When executing the SP in Query Analyzer, I got this error:
“Msg 8115, Level 16, State 6, Line 49
Arithmetic overflow error converting float to data type numeric.”
My next step was to get the source for the SP, commenting out the CREATE statement, and declaring and setting the parameters as variables to change the SP source code into ad hoc executable statements. By plugging the dates in question into these variables, I got the same error as above.
The line causing problem in the stored proc updated a table variable based on values from a static table. Since I could not directly determine what values in the static table were causing the SP to throw the error, I read in all of the values that were in the column of the table variable that were normally joined to the static table into a cursor.
I then scrolled through the cursor, using SELECT statements that contained a modified version of the expression that had been in the UPDATE statement, until I found out which value caused the problem. Also, I added two SELECT identical statements to the cursor, one before and one after the SELECT statement that had been modified from the original UPDATE statement. These two SELECT statements simply read “SELECT <<cursor variable>>” to indicate which value was being used for each iteration through the cursor.
When the value causing the problem was reached, the error statement appeared in the Messages pane of the Query Analyzer between two lines, each of these lines showing the value that caused the error. By then using that value in the WHERE clause of a SELECT statement against the static table, I was able to find out what bad data had been entered.