Log errors at application or database level?

[BFarley]

My ASP.NET application uses a SQL Server 2008 database.

Very few data operations would happen outside of the ASP.NET interface, and then only by system admins on rare occasions.

Would there be any downside to logging errors from within ASP.NET only?

My thought is that I'd use the Exception Management Application Block to publish errors to a table (or, if the DB is unavailable, an XML or text file) as they happen in ASP.NET. I would be able to log the necessary SQL details, such as procedure name and line number as those are returned by SqlException.

I don't want to create two separate entries for each error that pops up (one as ASP.NET error bubbling up to the Catch SqlException line, one on the database side).

Thanks in advance. Hope this makes sense.

Bryant Farley

"The Dude Abides

 

[jmeckley]

there are many guidlines for catching and handling errors. google "rules for exception handling" for more details on that.

your on the right track using a logging framework. whether you should log at the db level or application level is a design choice.

I treat my databases just as a stored container. the core of my design rests in the code, so I wouldn't bother with configuring sql to handle exceptions (other than administrative stuff, but that should happen regardless of the applications connecting to it.)

don't make your logging to fancy or complex or your logging will become to fragile to trust. I typically log to 2 - 3 destinations to ensure the exception is logged somewhere. usually a rolling log file and email. On large enterprise apps I would probably go with a messasge que and database logging.

if logging becomes a bottleneck check out async logging adapters, most logging frameworks have this feature.

finally, when to log. I allow my exceptions to bubble up and log at the global_error handler in the Global class (small apps). Recently I have switch from webforms to MVC (Monorail) I also log using a RescueController. this is specific to Monorail. not sure if MS MVC has a similar concept. In a larger app i would introduce more complex logging. I just haven't had a need for anything more than top level logging at this point.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[BFarley]

Here's my thinking. If an error is thrown in a SQL stored procedure, it will be caught by error handling in ASP.NET (whether in page, BLL, or DAL) as SqlException.

Logging the SqlException will tell me exactly where to look in terms of stored procedure and line number.

In this case, other than rolling back transactions, and perhaps some testing for logic (example: when adding a department, check first to see if department name exists & then do a RAISERROR), should I not be concerned with SQL error handling code?

FWIW I realize that in the example I cited, I should check at the BLL level to make sure an invalid value never makes it to the database, and plan to do that.

I've been looking thru code for Exception Management Application Block (EMAB) and found some really good ways of configuring multiple logging mechanisms.

I've also read that adding error handling in too many locations causes performance issues, so I'm trying to be careful to code properly. Some resources on N-tier programming just arrived so those will be a good guide.

Thanks!

Bryant Farley

"The Dude Abides

 

[DavidKuhn0422]

I would look into Aspect Oriented Programming (i use Spring.NET)

http://en.wikipedia.org/wiki/Aspect-oriented_programming

and use some logging framwork (log4net) to handle logging.

I also try to use the database for storage only. Log the errors in at least 2 places, you can use DB for one and some other form (xml, windows errors, etc) for the other. I like to send my errors directly to my bug tracking system so that the developers can begin to look at it immediately.

I think you are on the right page to deal with logging on the ASP.NET level and not in the database.

I've also read that adding error handling in too many locations causes performance issues

I would suggest worrying about optimization later. Without working error handling, your code will not be as robust.

 

[jmeckley]

I would look into Aspect Oriented Programming...
I also try to use the database for storage only....
I would suggest worrying about optimization later.

I think will get along great

Jason Meckley
Programmer
Specialty Bakers, Inc.