Just a little on the DB side
Even with the biggest applications we build sometimes we tend to forget the over nights we spend debugging solutions cause solutions are missing verbos logging/tracing, without that the only way to really debug code is to read event logs generated by the platform or guessing and both not really that informative.
Add to that the fact even with the most sophisticated piece of software you have to go at some point of time read/write data that actually resides on a data store implemented by SQL server or others. Hence most of time even when have verbos logging we don’t get DB messages, errors (with low severity from the database, using RAISE ERROR statement), print messages. These things are very important to look into specially with data intensive systems. What has been always nagging for me is formulating a method where you can grab these messages into your verbos logging without the need to do major changes to you infrastrcutre here is one out of DAPG (Data Access Practice Guide, found on http://msdn.microsoft.com/practice).
public string GetProductName( int ProductID )
{
SqlConnection conn = null;
try
{
conn = new SqlConnection("server=(local);Integrated Security=SSPI;database=northwind");
// Register a message event handler ---- hook to events, here is where you need to check your flags.
conn.InfoMessage += new SqlInfoMessageEventHandler( MessageEventHandler );
conn.Open();
// Setup command object and execute it
. . .
}
catch (SqlException sqlex)
{
// log and handle exception
. . .
}
finally
{
if(conn != null) conn.Close();
}
}
// message event handler
void MessageEventHandler( object sender, SqlInfoMessageEventArgs e )
{
// if you are only checking flags here you are costing yourself another function call.
foreach( SqlError sqle in e.Errors )
{
// Log SqlError properties
. . .
}
}
Notes on the approach:
- Consider having a factory pattern implemented to “factor” your connection and actually hook to events according to logging flags. That eliminates the need for your developers to actually write this code everytime they write DB access code.
- Always use flags for your verbos logging, verbos logging is a performance killer.
- Best flag is build flags are using #define. (all you need to do is to replace bins to get your verbos to work).
- For Web Apps you may define 2 levels of logging one of them is enabled using web.config which is light logging, the other is verbos defined just as previously stated
- Even on the database always maintain flags on Proc/Function level that controls verbos logging, be aware that changing them on Oracle takes a DB Object Recompilation which may cause errors if you have connection pooling enabled.
- Careful for what you log, cause too much logging will kill J seriously sometimes too much information may miss lead you.
- ALWAYS use none enabled verbos logging for production environment
- Enterprise Library Logging Application Block fits nicely with this approach