SQL CLR Aggregate function Error Handling - sql-server-2005

I have a user defined CLR aggregate function that can potentially throw an error. I would like to know how to handle an error if one occurs in my query.
The function is performing an IRR calculation similar to that which Excel does, ie. an iterative root-finding calculation. If no root is found, an error is thrown. This is the error I need to handle.
The query is part of a larger stored procedure and it looks something like:
select
MyID,
Excel_XIRR(col1)
from #t
group by MyID
and the error i get is something like this:
A .NET Framework error occurred during execution of user-defined routine or aggregate "Excel_Xirr":
System.ArgumentException: Not found an interval comprising the root after 60 tries, last tried was (-172638549748481000000000.000000, 280537643341281000000000.000000)
System.ArgumentException:
at System.Numeric.Common.rfindBounds#59(FastFunc`2 f, Double minBound, Double maxBound, Double precision, Double low, Double up, Int32 tries)
at System.Numeric.Common.findBounds(FastFunc`2 f, Double guess, Double minBound, Double maxBound, Double precision)
at System.Numeric.Common.findRoot(FastFunc`2 f, Double guess)
at Excel_Xirr.Terminate()
My problem is that not all the rows cause this error. There are some legitimate results from the query that I want to capture and use later in my stored procedure. Will this error stop me from getting the results of the query? If so, is there a way to figure out which rows throw the error (dynamically) and then rerun the query for the rest of the rows?

Not sure how well you have coded the XIRR function itself, looking at your function prototypes in Error messages it would seem you are using a Bi-section method of finding roots which is not most suitable to algorithms to use when it comes to finding rates. You will be locking yourself within a lower and upper bound no matter how large this bound is it is not going to help for all cases
As for solving your immediate problem with handling the error, you can change your .net code and replace the Throw...Exception statement with a return value of Math.Pow(-1, 0.5)
This will return a NAN to the calling program which you can then check with an IF statement to confirm whether your XIRR value is a number (when IRR is found) or a NAN value (when IRR is not found)

Related

What does "<8>" mean as a value?

I'm getting an exception report from a vb.net Windows Forms app I made via the exception reporting system I built into it. Some users are getting an exception with message "Value was either too large or too small for a Decimal.Couldn't store <8> in PrdHrs Column. Expected type is Decimal."
The stack trace included tells me the method, and that message narrows down where the exception is being hit, but I can't figure out what "<8>" means. Does that just mean the value of 8, but it's displayed with less than/greater than symbols around it? Or does that imply a certain value type? Google is basically impossible to search for this.
I suspect that that '8' actually is an infinity symbol but it's not displayed properly in whatever you're seeing. I just tried this code:
Dim dbl = Double.PositiveInfinity
Dim table As New DataTable
table.Columns.Add("Number", GetType(Decimal))
table.Rows.Add(dbl)
and this was the message I got:
System.ArgumentException HResult=0x80070057 Message=Value was either too large or too small for a Decimal.Couldn't store <∞> in
Number Column. Expected type is Decimal. Source=System.Data
StackTrace: at System.Data.DataColumn.set_Item(Int32 record, Object
value) at System.Data.DataTable.NewRecordFromArray(Object[] value)
at System.Data.DataRowCollection.Add(Object[] values) at
ConsoleApp1.Module1.Main() in C:\Users\johnm\AppData\Local\Temporary
Projects\ConsoleApp1\Module1.vb:line 12
Inner Exception 1: OverflowException: Value was either too large or
too small for a Decimal.
It's not ideal that you are working with Double values and then storing the results as Decimal values. It may be unavoidable but, if so, you need to do a bit better at validation. You are probably dividing by zero, which is legal for Double values and produces either Double.PositiveInfinity or Double.NegativeInfinity.

MS Access: The expression you entered is too complex

I'm trying to call this VBA function in the following update query and I'm getting this error. I'm stuck and I don't know what to do. The function signature seems ok to me.
Compute([ep].[ReferenceNumber],[ep].[ITU3Number],[ep].[AuthorizationNumber],[ep].[Ent],[ep].[Indicator],[ep].[LineCode],[ep].[ProductLinee],[ep].[Inp_ProfitCenterCode],[ep].[Inp_ParisBOCode],[ep].[StartDate],[ep].[EndDate],[ep].[ExtractionDate],[ep].[OffBalance],[ep].[IType],[ep].[Counterparty],[ep].[WAL],[ep].[Inp_BackupLineIndicator],[ep].[Indicator],[ep].[FinalRating],[ep].[Amount],[ep].[Currency],[ep].[Historical],[ep].[rice],[ep].[MaturityIndicator],[ep].[pproachType],[ep].[SignatureDate],[ep].[IMaturityDate],[ep].[ProductType],[ep].[Inp_StepupDuration],[ep].[ProbabilityOfStepup],[ep].[SCF],[ep].[ICollateralSCF],[ep].[MobilFlag,[ep].[MarginBp],[ep].[ExtensionCode],[ep].[ExtensionYear],[ep].[UsageType],"a","a")
The expression is too long for Access to process:
The maximum acceptable length appears to be around 560 characters The maximum number of arguments seems to be 29.
For example, by truncating some fields, this works:
Compute([ep].[ReferenceNumber],[ep].[ITU3Number],[ep].[AuthorizationNumber],[ep].[Ent],[ep].[Indicator],[ep].[LineCode],[ep].[ProductLinee],[ep].[Inp_ProfitCenterCode],[ep].[Inp_ParisBOCode],[ep].[StartDate],[ep].[EndDate],[ep].[ExtractionDate],[ep].[OffBalance],[ep].[IType],[ep].[Counterparty],[ep].[WAL],[ep].[Inp_BackupLineIndicator],[ep].[Indicator],[ep].[FinalRating],[ep].[Amount],[ep].[Currency],[ep].[Historical],[ep].[rice],[ep].[MaturityIndicator],[ep].[pproachType],[ep].[SignatureDate],[ep].[IMaturityDate],[ep].[ProductType],[ep].[Inp_StepupDuration])
This works:
Compute(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29)
But this fails:
Compute(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30)
So, you could do something like this:
Compute(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,SubCompute(29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56))

Arithmetic operation resulted in an overflow

When i send:
Result = CInt(NetApiBufferFree(pBuffer))
I receive (SOME TIMES) this error:
Arithmetic operation resulted in an overflow.
What exactly means that? and how i can resolve it?
It means that CInt argument is out of range of Integer, -0x80000000 to 0x7FFFFFFF
And it happens when NetApiBufferFree returns an error: error codes are bigger than 0x80000000.
There is no unsigned int32 type, so use CLng instead of CInt.
About source of error. You should find out code of error which you get: call MsgBox or log it to file, or use breakpoint. Next find its description. If it won't help you (for example error would be E_FAIL), add code to check that pBuffer value is valid - that it wasn't modified by something, and wasn't already freed. Add logging for NetApiBuffer* calls.
Best answer is replace 'double' in place of 'Int16/Int32/Int64'
some times file conversion takes huge numbers.. double never has maximum range.

Failure to Pass Arguments to a UDF in VBA for Excel 2007

I have a complex iterative spreadsheet in which I want to use a UDF to calculate the heat transfer coefficient of a heat exchanger. The function has 5 arguments (2 strings and 3 doubles). The strings and 1 double pass just fine. The remaining two don't seem to go through at all. A watch on problematic arguments shows them to be equal to zero. I tried redefining the arguments as variants, and then I can find the value I want in the "value2" field. However, as soon as I try to access it (via varName.Value2) it disappears (the watch suddenly lists the field as "Empty").
The cells passed into the function for the problematic arguments are heavily dependent on the rest of the spreadsheet, and their value changes almost every iteration.
Has anyone seen this before and know of a workaround?
I use UDFs with +6 input variables (the standard types as well as variants), and I have noticed (this is my interpreation of what happens) that sometimes the excel calc engine tries to trigger the UDF before all the input values become calced and available. From the debug view this is seen as the function making "false starts" and stopping to execute mid-procedure (thread is lost) so debugging-wise it shows a strange behaviour.
However, when written into a cell the function still calculates and returns correctly.

Divide by zero error in stored procedure

Hi i executed the following stored procedure in .net web application. Then run the application. I got this error
" Divide By zero error "
Stored procedure:
CREATE procedure Details(#Stringtext varchar(8000),#SearchStringtext varchar(100))
as begin
SELECT ({fn LENGTH(#Stringtext)}-
{fn LENGTH({fn REPLACE(#Stringtext, #SearchStringtext, '')})})/
{ fn LENGTH(#SearchStringtext)}AS String_Count
end
Evidently:
{ fn LENGTH(#SearchStringtext)}
... is evaluating to zero.
The length of the SearchStringText is Zero and hence there is divide by zero error.
Make sure that when the function is called, the string is of non-zero length.
Alternatively check for length before doing the select
{ fn LENGTH(#SearchStringtext)}
is evaluating to 0.
However, why is this a stored procedure? You are not using any db feature? Unless this is a simplified problem , all this (length, replace etc) could be done in your .net application
If SearchStringtext is empty, the length of it becomes 0. Thus the stored procedure tries to divide by zero (which is an undefined thing to do).
In other words the following part becomes zero:
{ fn LENGTH(#SearchStringtext)}
You might want to add some logic (if statement perhaps) to prevent the division to happen if the SearchStringtext is empty.
The only division operation in this procedure, has fn LENGTH(#SearchStringtext) as the divisor.
Hence it seems that length of **SearchStringtext** is evaluating to zero. It might be possible that you are trying to search an Empty string.
Please check and then elaborate the question details, along with the DB platform.
It seems that the length of SearchStringtext is 0 -- so the procedure tries to divide by zero.