Level of effort extending Database Listener by one column

Topics: Building and extending application blocks, General discussion, Logging Application Block
May 17, 2012 at 5:04 PM

Having been accused of doing things the hard way I need a sanity check here.  All I want to do is add an additional column to the logging database to account for Application ID and have this value read in from the config file. 

I created a new class ExtLogEntry that extends the LogEntry object that is merely get/set for my new field Application

I added the column and modified the stored procedure.  The WriteLog stored proc works with no issues.

I understand that I cannot inherit from anything other than the CustomTraceListener so I have.  I have overridden the Write methods and added custom code to call the stored proc with the additional parm.  Here starts my questions/dilemma

1.  The database trace listener wraps up things like the database name, stored proc name into the listener declaration.  This is nice and tidy for reuse.  Do I really have to abandon this?  I need to get the database name, stored proc name, & application name (new field) from somewhere.  At a previous company a developer hacked the source code to take app name but I'm trying hard not to.

2.  One of the web examples I found overrides TraceData.  I don't have the source code but I can see that it is called in the Logger.Write pipeline before the actual write method.  Curious what its intent was

3.  If I do have to pull in my dbName, Stored Proc name, and application name from a seperate part of my config file where do you store this info? 

Thanks.  For what I am tryind to do, the level of effort is totally disproportionate and I can't believe I am on the right track. 


May 17, 2012 at 8:34 PM

Don't recall as of now if the default DB schema has the following column, but if you don't want to add extra effort I *think* you could leverage the ExtendedProperties:

Dictionary<string, object> props = new Dictionary<string, object>();
props.Add("ApplicationID", myApplicationID);

LogEntry le = new LogEntry();
le.Title = "New log entry!";
le.Message = "This is a new log entry";
le.ExtendedProperties = props;

Another idea here, if your ApplicationID value is a GUID you could use the ActivityId field of the LogEntry class to store it...

Maybe something like that could work... However maybe you won't be able to query the info so easily... Otherwise you'll have to alter the schema and stored procedures (not difficult at all, done it in the past, just time consuming).


May 17, 2012 at 8:44 PM

Looking around I found a sample that you may be able to use (the first one on the page):


Kind regards.

May 18, 2012 at 6:21 PM

I think I have managed to get through this.  I could use Attributes in the Listener definition to add my additional field requirements.  I'm still disappointed there was no way to hook into the existing db listener but c'est la vie.  Thank you for the insights.