If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

Troubleshooting .Net SQL Connectivity issues: What data should you gather?

Troubleshooting .Net SQL Connectivity issues: What data should you gather?

  • Comments 3

Spike in our data access support team has a really good blog talking about data access related issues in .net.

Recently he wrote a really good post about what you should gather to troubleshoot a connectivity issue effectively such as

  • Connection strings
  • SQL Server logs
  • The exact error message (with stack trace and other details)
  • Netmon traces
  • Memory dumps
  • File version info

along with what you should look for in each…

I would recommend both that post and the blog as a whole to anyone dealing with data access related issues.

  • PingBack from http://www.anith.com/?p=1340

  • A decently written application will log all sorts of connection information to its log file such as

    1. messages before reading config entries

    2. exceptions  from missing/mangled config entries

    3. messages before any connection related .NET api calls

    4. message after any net connection related api call giving the return value and possibly an object dump

    5. message for any .net connection related exception  giving the exception text/dump

    Generally, you should log unique identifiers for the code line logging the message even in the format FUNCTION_NAME__FILE_NAME__LINE_NUMBER__MESSAGE_TEXT___data_fields

    This should be in a grep'able format for integration into your system monitoring system (openview, mom, patrol, etc).

    Too often, I've seen/diagnosed/fixed systems that have a generic 'exception occured' message displayed to the end user and support person without a unique identifier or error ID number.  This adds hours to the total time needed to diagnose/fix the connection problem

    Case example:

    1. connection fails

    2. web page displays 'connect failed: code: FNTXI_01_222"

    3. Ticket gots to help desk

    4. Help desk looks up "FNTXI_01_222" for resolution document.  If resolution document found, then follow steps in it to either fix the problem or get more information to put into the helpdesk ticket

    5. If not fixed, help desk send error message and ticket to developer

    5. developer opens VS and the project

    6. Developer searches for "FNTXI_01_222" in all files in the project and double clicks on the exact line that failed

    7. Developer fixes problem or contacts help desk to remedy the problem

    8. If application bug, then a child ticket is created referencing the help desk ticket with the bug, where it happened, what could cause it, how to fix it (even a guess is better than nothing), date/time, source code name, function name, etc.

    These basic production development shop processes are lost on most recently in the development profession.

  • Thank you for submitting this cool story - Trackback from DotNetShoutout

Page 1 of 1 (3 items)
Leave a Comment
  • Please add 2 and 6 and type the answer here:
  • Post