If you're ever writing a commercial application that you're going to license to other companies for resale, do them a favor and don't write EVERY ERROR/EXCEPTION to a SQL database.

I'm looking through the error log of a business we license a web application to and trying to find out why the shipping methods are broken.  The error log goes all the way back to January 2005, so I decide to execute a custom query:

[code]
SELECT [ID]
      ,[EventTime]
      ,[Source]
      ,[Message]
  FROM [thebarkeryetc].[dbo].[bvc_EventLog]

  WHERE [EventTime] > 'Nov 1, 2006 12:00:00 AM';
[/code]

7 minutes and 22 seconds later, 91,481 rows have been returned and I'm only up to November 6 at 6:30 am.

This is SO ANNOYING.

I'm guilty of this, boooy will Jeff be pissed.

ROFL :P  I log everything too.  Though lately I've been putting errors in different logs depending on severity.

It's fine to do error logging to the database, just follow some common sense.
* Establish severity levels in your log messages.
* Allow the program administrator/operator to inspect and alter the current severity level.  If they're troubleshooting something, setting it to a more informational level should add more detail to the logs.  Setting it back to error/production should produce less information to the logs.
* Have a trigger in place that deletes rows older than an age threshold, or when the number of messages exceeds a count threshold.
* Finally, the logging database should not be the same as the database the program uses for its production data.  If the database itself is the problem, or the database server, you want your diagnostics somewhere not affected.  For this reason, I prefer text file for logging errors.

More about logging.
* Log positives as well as errors.  If you program performs some work, a single-line information entry should be made indicating the datetime, unique customer key such as an item number, inventory control #, and what was done to it.  i.e. "2006-11-15 03:56:02 Group: ATX43 Claim: G0823462T was filed to IMGSVR04 slot YUG005"

I know a lot of programmers who think there's no reason to log successes their program does, but they're wrong.  Just this month one of my customers had to restore several integrated servers back to an October 12th state, and then reprocess any work that had been done between Oct 12 and Nov 1.  On all programs that were written by me they merely had to scan my log files to know precisely which work had to be redone.  On all their programs they realized they were guessing and totally relied on intuition as to what work had to be redone.