DB2 SQL Statements throwing Exception
The following is occurring for a nice .NET web application.
All of my DB2 SQL statements (SELECT, UPDATE, INSERT, CALL,.....) are getting an ArgumentException of "Requested value 'SELECT' was not found".
The c# try/catch does not fire that there was an error. If fact, the application works just fine. Dynatrace just shows an Exception after all DB2 calls.
Most calls are ExecuteReader() method calls.
I do not see this occurring for any Oracle related calls.
Ideas?
dynaTrace shows ALL exceptions that happen in your application - even those that are caught within the frameworks you are using. So - it is very likely that these exceptions are caught within the ADO.NET Framework and therefore never make it to our application code.
However - knowing that these exception occur - you could do some research to find out whether it is due to a configuration issue. Exceptions in general might not be bad - but - could be bad if they happen very often and if they can be avoided. In the end - every exception that you can prevent is time and performance saved
Andreas,
That is great. I see them. I cannot get a ArgumentException to be detected when running a debug on my computer in Visual Studio.
Do you have a suggestion as to how I can make Visual Studio more sensitive to capture the System.ArgumentException that DynaTrace is detecting?
I have tried a couple changes to the VS debug parameters to no avail.
I am not an expert in VS Debugging - but I know that there is a debugging setting that allows you to specify a list of Exceptions that will put a breakpoint when a certain exception is thrown. I am sure these exceptions - or better - the location where this exception is thrown - is currently not included in that list
I did find a checkbox specifically for "System.ArgumentException". So far, no luck. I will keep checking.
Does DynaTrace have a more detailed "dump" list? I am looking only in the PurePath lists so far.
I have dug a little deeper: Throwing Class = System.Enum, Throwing Method = Parse.
I'm getting closer.
hi Steve,
doesn't the stacktrace of those exceptions already give you a good hint on where they occur?
you could also post the session here for us to look at.
best,
Christian
Christian,
Sure. I can identify each DB method being executed.
In VS 2012 Ver 11, in debug mode, I have tried a variety of methods to try and capture the ArgumentException.
try{}/catch{} does not capture an exception. The SQL statements work, return data, application functions as though nothing was wrong.
Every SQL statement, be it SELECT, UPDATE, DELETE, via ExecuteReader() or ExecuteScalar(), gets that neat little "exception" line red-x.
When I can get DynaTrace into another server location I can try some other DB2Command changes to see what (if any) will remove the exceptions.
I should be doing that in a day or two.
Thanks.
I think what Christian wanted to say is that you can right click on that Exception and open the Details Dialog. That will give you the FULL Stack trace for that Exception and "not just" the information in the PurePath which is typically not as deep as the stack trace.
Another hint for folks that are new to dynaTrace: You can open the Exception Dashlet (double click on it in the Cockpit). There you get the overview of all exceptions captured within e.g: the last 30 minutes. From there you can see the Details (Full Stack Trace) + you have the Option to Drill To those PurePaths where these exceptions are thrown.
Andreas,
I found the Stack trace. The exceptions seem to be part of the ADO.NET handling of the DB2 call.
Learning much about DynaTrace as well as about IBM.Data.DB2.DB2Command structure and syntax. But not close to solving this.
Steve,
it's a little hard to tell, because obviously the DB2 driver assembly was obfuscated. so if you're interested in what's going on inside the DB2 driver, I'd suggest the following:
- place method sensor rules for all the methods in the DB2Command class or at least the ones you see on the stacktrace above via the class browser (system profile -> sensors -> browse...) and turn on parameter and return value capturing for all parameters and return values. this should show you all the methods from the stacktrace also in the PurePath with the arguments/return values of the calls.
- compare these method calls with the ones found in the (decompiled) DB2 driver. if you don't want to to this yourself, you could also export the resulting PurePaths and attach the dynaTrace session to this forum thread and I'll take a look at it.
- additionally it would be very helpful to know which DB2 driver version you use. you can figure this out by finding the IBM.Data.DB2.x.y.z.dll (e.g. IBM.Data.DB2.10.5.0.dll) and look at x, y, z. it would also be very helpful if you could attach this dll, too.
hope this helps,
Christian
Our application is currently using IBM Version 9.0.0.2. I will see about having that improved.
correct, Andi explained it in more detail, but that's what i meant. 
so with the full stack trace you should also see what the DB2 driver is doing inside.
I'm no expert in VS debugging, either, but i could imagine that setting breakpoints in code which is built as release without debug information - as the DB2 driver surely is - does not work. and of course you cannot catch the exception in your code, because it is thrown and caught below the DB call ... otherwise, if it would be thrown over the DB call, you would see a red cross icon on the DB call in the PurePath.
For now I just decided to go to "Sensor Configuration" and enter an "Exclude" entry for System.ArgumentException where the argument contains "Requested value". Now it is not counted or displayed as an exception.
Thanks for your time.
