excuse the ignorance on my part, but not sure how to do that?
Hi, no problem at all!
You will find the corresponding snippet when looking for "error":
You need to convert your final number to a string simply by adding a ".toString", e.g.:
Dim dDec As Decimal = 1
Dim sDec as string = dDec.ToString
Then you can log this as follows:
BRApi.ErrorLog.LogMessage(si, "My string value: " & sDec)
You then need to run the calculation (by opening your report) and then check the error log for the result. Likely you will see a number such as 0.000000000000000000000000000000000000000000000000000000000000000000000001 which will then tell you graphically (and as others said in their posts) why the system cannot handle this as the result likely falls out of the decimal range.
Please note that you should not open your standard report, but create a test report that contains only a single cell! And this single cell should be the one returning your error. This is because otherwise you would write the result of each cell into the error log. That is not advisable as (1) it is a slow process and might take a while in particular for large reports as the snippet I showed you uses a BRApi and (2) you will otherwise see many numbers in the error log and you may not be able to locate the one causing the error easily. Also, do that in a test environment where only you are working on. If that log is accidentally triggered by many other users at the same time, performance will suffer and the log will be flooded.
Very important: Deactivate / delete the error log function after you used it!
Thanks for the thorough explanation and detail. I do see a long number, but can't seem to figure out how to round or convert it to a double. I tried Daniel's idea below, but to no avail. Any ideas?
You want to round the CellAmount to something safer before you raise it to a power. 6 decimals should give you enough room, go lower if the error persists (assuming ExponCAGR is not crazy).
Math.Round(CAGRCalc.CellAmount, 6) ^ ExponCAGR - 1.0
If this loss of precision is unacceptable, you can convert the Decimal to a Double by assigning CAGRCalc.CellAmount to a variable of that type, and perform the calculation with this new variable. However, double-based arithmetic is not exactly the same as decimal, so results could be surprising to non-programmers. Generally speaking, we typically recommend to stick to Decimal for financial data.
Hey Jack - this was the solution that Daniel mentioned below. I tried this, and even today by rounding to 0. Still no luck resolving the error.