OK, I can see your point of view. For example, my son doesn't think that cleaning up his room falls under the scope of a child, and proposes that it be done by a separate housekeeper.
Just kidding, this is no big deal. What about flushing the output buffer? We are building a log viewer application. Before it makes a display for the user, it needs to issue a command to flush the buffer so the user will be able to see the most recent entries. -----Original Message----- From: Ron Grabowski [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 3:02 PM To: Log4NET User Subject: RE: Buffer Flushing and Table Maintenance in the ADONetAppender Personally I don't think that database maintenance falls under the scope of a logger. If you really want that functionality, a good starting point may be to introduce <timer> nodes for the AdoNetAppender appender that executes <commandText> when a <datePattern> changes: <appender ... > <bufferSize ... /> <connectionType .../> <connectionString ... /> <commandText ... /> <parameter ... /> <parameterName ... /> <dbType ... /> <layout /> </parameter> <timer> <!-- delete DEBUG level records every month --> <datePattern value="yyyMM" /> <commandText value="DELETE FROM Logs WHERE [Level] = 'DEBUG'" /> </timer> <timer> <!-- delete all records older than 12 hours every day --> <datePattern value="yyyMMdd" /> <commandText value="DELETE FROM Logs WHERE [date] < DATEADD(Hour, -12, GETDATE())" /> </timer> </appender> I just made up those sql statements so they probably cancel each other out in terms of what data they delete. I would imagine some people would want some <commandText> executed every XX log entries. I can't think of a good way to express that. I've looked at some of the elements that make up a RollingFileAppender but those don't convert well to databases... - Ron --- Howard Weisberg <[EMAIL PROTECTED]> wrote: > If someone implements the Table Maintenance part, I think it should be > configurable by Level and also by expiration date and/or maximum > number of rows. > > -----Original Message----- > From: Burger, Erik [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 14, 2005 3:48 AM > To: 'Log4NET User' > Subject: RE: Buffer Flushing and Table Maintenance in the > ADONetAppender > > Hi Howard, > > As far as I know, you have to roll your own. What I did (probably not > the only way) is add a Job to the SQL Server Agent to execute the > following T-SQL command every hour: > DELETE > FROM <tablename> > WHERE [date] < DATEADD(Hour, -12, GETDATE()) > > This will delete all entries older than 12 hours. Of course, the > [date] field might differ per configuration. In my particular case I > needed to save the date and time as two separate strings to support > legacy code. > My command is therefor slightly more complicated :) But it works well. > > I would love to know if there is a better way of doing this. Also, a > configuration setting in log4net would be great! If I had the time I > would try my hand at it myself. Being able to limit either the age of > entries or the number of rows would be a godsend. Maybe (but that > would be pushing it a > bit) it would even be possible to 'relog' the soon-to-be-deleted rows > to a FileAppender or SmtpAppender. > > Mmmm..coolness.. > > Anyway, hope this helps, > Erik > > ------------------------------- > Lead Developer > Research and Development Group > GPXS Wireless Ltd. > Southampton, United Kingdom > Phone: +44 (0) 23 8076 2519 > Fax: +44 (0) 23 8076 2555 > Email: [EMAIL PROTECTED] > > > -----Original Message----- > From: Howard Weisberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 13, 2005 7:36 PM > To: [email protected] > Subject: Buffer Flushing and Table Maintenance in the ADONetAppender > > > Is there support for programmatically flushing the buffer? > > Is there support for deleting records in the SQL table that are older > than a specified amount (to keep the table from growing without > bounds) or do I need to roll my own? > > > > The information contained in this e-mail and any attached documents > may be privileged, confidential and protected from disclosure. If you > are not the intended recipient you may not read, copy, distribute or > use this information. If you have received this communication in > error, please notify the sender immediately by replying to this > message and then delete it from your system. > > The information transmitted by this e-mail message is intended solely > for the use of the person to whom or entity to which it is addressed. > The message may contain information that is privileged and > confidential. > Disclosure, dissemination, distribution, review, retransmission to, > other use of or taking any action in reliance upon this information by > anyone other than the intended recipient is prohibited. If you are not > the intended recipient, please do not disseminate, distribute or copy > this communication, by e-mail or otherwise. Instead, please notify us > immediately by return e-mail (including the original message with your > reply) and then delete and discard all copies of the message. > > Although we have taken precautions to minimize the risk of > transmitting viruses we nevertheless advise you to carry out your own > virus checks on any attachment to this message. We accept no liability > for any loss or damage caused by viruses. > > > The information contained in this e-mail and any attached documents > may be privileged, confidential and protected from disclosure. If you > are not the intended recipient you may not read, copy, distribute or > use this information. If you have received this communication in > error, please notify the sender immediately by replying to this > message and then delete it from your system. > The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system.
