I had that same thought. There are a couple of problems I saw with that, though. The LoggingEvent object is passed in by value, through several intermediary objects. Each of those would have to be changed, which would affect five or six objects just to change them to use reference parameters.
Also, in one of the objects besides the ADONetAppender there is a function called AppendToAllAppenders or something like that. This is where the return array of integers would have to be constructed, so I'd also have to rewrite that. By the way, I tried inheriting from ADONetAppender to make the appender changes, but that is a problem since all the member variables are private. Any way you could change all the private member variables/functions to protected so they can be inherited? I've done that in my downloaded copy of the code, but I pondered whether it should be an official change request. Aaron Hart -----Original Message----- From: Nicko Cadell [mailto:[EMAIL PROTECTED] Sent: Friday, December 17, 2004 10:01 AM To: Log4NET User Subject: RE: ADONetAppender - returning output parameters Aaron, The standard implementation of the ADONetAppender does not support retrieving results from the database query. You will need to create your own implementation that also retrieves a result from the database. The LoggingEvent has a Properties map that can be used to store additional data. You can write into the properties collection from your database appender. You could then retrieve this in your ILogImpl subclass. In you ILogImpl subclass you would need to do something like: public long LogMsgAndGetID(object message, System.Exception ex) { // Create the logging event LoggingEvent loggingEvent = new LoggingEvent(FullName, Logger.Repository, Logger.Name, Level.INFO, message, ex); // Log the event (appenders will run) Logger.Log(loggingEvent); // Retrieve the result from the event properties return Convert.ToInt64(loggingEvent.Properties["RecordID"]); } The code in the appender would do the following: override protected void Append(LoggingEvent loggingEvent) { long recordID = Write2DB(loggingEvent); loggingEvent.Properties["RecordID"] = recordID; } Note that there are several issues. If a single event is written to multiple database appenders then the RecordID property would need to be some form of collection rather than a Long. Also you would need some way to identify which ID returned belonged to which database. The ADONetAppender supports buffering LoggingEvents and then writing them into the database in a single batch. Obviously this would cause a problem as the event may not be written to the database during the Logger.Log() method, and therefore the RecordID property would not be set. The simplest solution to this is to write the events to the database without buffering. Cheers, Nicko > -----Original Message----- > From: Hart, Aaron [mailto:[EMAIL PROTECTED] > Sent: 16 December 2004 21:21 > To: [email protected] > Subject: ADONetAppender - returning output parameters > > I've inherited and extended the ILog interface and LogImpl > class and created a custom LogManager to allow custom > parameters to be sent to an ADONetAppender. > > Now I'm wondering: is there a way to get return values/output > parameters from the internal DbCommand that is used to insert > the record to the specified table? The reason I ask is that > it's possible that the table the logging information is being > written to might have an auto-increment integer (IDENTITY) > primary key field, so it would be nice to get that value back > after the insert. > > Stepping through the code, it looks like the LoggingEvent > used to pass in the properties gets passed through four or > five other functions as a parameter before the database > command is actually executed, so it would be difficult > passing values all the way back through all those functions. > I also know that there are potentially several other > appenders writing records to the database if other > ADONetAppenders were configured for the logger being used, > which makes it difficult to pass back parameters for all of them. > > Any ideas would be helpful. Thanks. > > Aaron Hart > Zoll Data Systems, Inc. > Broomfield, CO > >
