Improved command logging in ADO.NET provider for Firebird
I recently improved the command logging in ADO.NET provider for Firebird. Let me start with little bit of history and then you’ll see the motivation and current improvements.
Before I added simple Debug.WriteLine to the FbCommand class. This was mainly driven with need to easily see commands I was generating for Entity Framework. Then the Visual Studio 2010 came with the IntelliTrace (only Ultimate version) and while working with MS SQL Server I was happy to see commands without any additional effort. I wanted the same for Firebird too. Sadly the IntelliTrace right now isn’t publicly pluggable. I was still using the debugging code, but often when doing development on customer’s applications using released version of provider I lost this ability. No debug outputs, no IntelliTrace.
Because I believe it’s important to have easy way to see (and not only for Entity Framework’s generated) the command, to spot performance problems early, I added simple logging facility. This logging is enabled for all builds (not only debug) and uses Trace class from .NET Framework. Everytime you Prepare (the Prepare method is called also automatically before execute if not called manually) command you’ll see the command text and current parameter names and values (if any). If you’re inside Visual Studio you see by default the output in Output window. You can also configure it to log i.e. to file, probably usable in staging and/or production.
Hope you find this useful as I do.
There's 16 Comments So Far
August 16th, 2011 at 16:44
After upgrading to 2.6.5 I noticed a significant slowdown during debugging. What’s the best way to disable command logging during debugging?
Thanks.
August 16th, 2011 at 16:47
I believe you have problem somewhere else. There’s only one place, where the logging takes places and it’s not related to other parts of execution.
August 16th, 2011 at 16:52
Possibly. I have code that performs thousands of db inserts. When I run this code in the debugger it’s very slow and I can see each insert statement appear in the output window. When I run outside of the debugger it’s very fast. The slowdown did not occur in the previous version of the Firebird Client.
August 16th, 2011 at 16:54
Then simply do not allow VS to attach Output Window for tracing.
August 16th, 2011 at 17:31
Thanks for the quick responses. That is the reason for my question – disabling ‘All debug output’ in the Debugging\Output Window option does not work. What is the best way to disable these trace messages?
August 16th, 2011 at 17:34
Don’t know. Never needed that. In these cases I’m simply detaching debugger.
September 5th, 2011 at 20:27
FYI – you can add the following to the app.config file to eliminate the debug performance problem. The downside is that output from all other components using Debug.Trace is now invisible.
September 5th, 2011 at 20:29
Looks like the xml was cut from the post. Basically add “” to the listeners group in the trace group of system.diagnostics.
September 6th, 2011 at 09:34
Interesting. I thought VS always adds own listener.
September 20th, 2011 at 15:33
Hello
I also think that logging commands using standard Trace.WriteLine() is not such a good idea as it seems. In an application with a lot of commands:
1) It floods Output window, so it is very hard to find other information which are shown there.
2) Writing to visible window really makes running application from Visaul Studio slower if there are a lot of commands.
As Scot mentioned, trace output can be eliminated in app.config file, but this really disables all output from Trace class and this can be a problem. Fortunately we don’t use Trace class for our own trace output. But if we did so, we would end up with searching for our output among SQL commands (our app really uses quite a lot SQL commands), or not seeing anything.
I spent couple of hours reading something about using Trace in .NET and I think there is a solution. Do not use Trace.WriteLine() in TraceHelper, but use own TraceSource for writing. I did not try it, but it should be possible to set different listeners for different trace sources and thus to filter trace from FirebirdClient.
October 31st, 2011 at 17:50
Well,
seems I cannot use the 2.6.5 version then.
I’ll have a look how far I have to go back until I find a FirebirdClient assembly that doesn’t make any use of the debug system impossible.
Yours,
Sebastian
November 16th, 2011 at 16:54
This was concerning me as well. Here is my workaround. I don’t think it is any faster, but at least the messages do not show up.
public class FilterDefaultTraceListener : DefaultTraceListener
{
public override void WriteLine(string message, string category)
{
if (category == “FirebirdClient”) return;
base.WriteLine(message, category);
}
}
Implement in application
// Added to be able to filter out specific trace output (FirebirdClient)
Trace.Listeners.RemoveAt(0);
Trace.Listeners.Add(new FilterDefaultTraceListener());
March 9th, 2012 at 15:21
How can I turn it off? I don’t need it.
March 9th, 2012 at 15:33
http://blog.cincura.net/id/232603/
Who Linked To This Post?
Share your thoughts, leave a comment!