Logging to some different tables than Log, Category and CategoryLog

Topics: Logging Application Block
May 15, 2010 at 7:05 AM


In our project we have started using the “Enterprise Library 4.1 - Oct 2008” version.

This question is related to using ‘Logging Application Block’ for logging information to a different table than what is used in the default ‘database trace listener’. 

We are trying to log information to existing log tables using already written SPs. These (table structure and SPs) are widely different from, the typical ‘Log’, ’CategoryLog’ and ‘Category’ kind of tables which I’ve seen in default database trace listener implementation.

How can we use the LAB to pass, some custom information (different than what's shown in default db-trace listener) to log to our own logtables in database.

We are using the ‘Logging Application Block’ for the first-time and struggling to understand, how to achieve this.


It'll be very useful, if you could share, some sample code, guidance, tutorial or step-by-step information, to achieve this.

May 17, 2010 at 1:58 AM

You would need to create a custom trace listener. For reference on how to do this, here is the link - http://msdn.microsoft.com/en-us/library/ff647545.aspx.  Or you can check out the documentation that comes with the installation.

For adding additional information, you can create a custom class that inherits from the LogEntry class.  Add the extra properties that you need. 

In your custom trace listener, make sure that you check if the passed object is an instance of your custom LogEntry object, or a simple LogEntry object, or a string, or any other type you think it might be.  Add codes which formats and write each type of object to the database table. 

We have a sample custom database trace listener, if you want a copy, just email us at entlib.support@avanade.com.


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

May 17, 2010 at 11:07 AM

Thanks a lot Sarah.

May 21, 2010 at 12:26 AM
Edited May 21, 2010 at 12:28 AM

As an alternative and to avoid the complexity of a custom trace listener for small variations or small additioinal data, could you not split things up inside the default WriteLog stored proc? Also, could you not parse the FormattedText inside the stored proc for simple things, like maybe a user name, etc. I haven't seen this approach discussed anywhere, although I am new to this forum. Just wondering if such would be a viable alternative. For the post above, could you not do something like:

Create Stored Proc WriteLog(@Parm1, @Parm2, @Parm3, @Parm4, @Parm5)
  Exec MyStoredProc1 @Parm1, @Parm2, @Parm3
  Exec MyStoredProc2 @Parm1, @Parm4, @Parm5

As an aside, thanks for the sample custom DatabaseTraceListener, very helpful. It would be even better if it actually hooked up to Northwind or AdventureWorks so that you could run it and see the results.

May 21, 2010 at 10:12 AM

That is possible j2associates, I just prefer the approach of extending the logging application block :)


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

May 21, 2010 at 11:14 AM
Edited May 21, 2010 at 11:20 AM

Hello Sarah,

1. I would agree, but sometimes you need a quick and dirty, say the User name only. It would be faster to just parse it out, especially if you don't work with the Enterprise Library on a daily basis.

2. One property the default formatters are missing is domain and user name. They pick up the machine automatically, but not the domain and user name (eg Domain\UserName). Is there any chance this could be added to the default formatters?

3. Is there any chance the custom DatabaseTraceListener example could be expanded to include a form interacting with it so you could see it run right out of the box?

I really appreciate the timely and helpful responses the support team provides on this board.

May 24, 2010 at 1:46 AM

Thanks j2associates.  I'll try to find time to include the sample app that uses the custom database trace listener.

And yes, I would also agree that your suggestion would be a quick and dirty solution. :)

On your second question, you could add a feature request in the Issue Tracker for that.  For the meantime, you can add that extra property in a logentry's ExtendedProperties so it would automatically appear in the log message if you include the token for the ExtendedProperties in the Text Formatter Template.


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.