Error messages are an essential tool for troubleshooting in SQL Server. They provide valuable information that helps identify and resolve issues. Over the years, the SQL Server development team has continuously improved the error messages, making them more informative and user-friendly with each release.

One often overlooked aspect of error handling is the logging of errors in the ERRORLOG file. This log file can be a valuable resource when it comes to diagnosing and fixing problems. Let me share an interesting incident that highlights the importance of error logging.

Recently, I received an email from a friend who was facing a strange behavior in their SQL Server environment. They were using a third-party software that utilized SQL Server as its backend. Additionally, they had a monitoring software in place that tracked messages in the Event Log and sent alerts to the Wintel team.

The issue reported in the email was related to a brute force attack on the ‘sa’ password. The monitoring software should have captured the login failure attempts and alerted the team. However, to their surprise, these messages were not logged in the application event log at all.

Curious about this anomaly, I requested the ERRORLOG file to investigate further. Upon examining the file, I discovered an interesting non-default startup parameter called “n”. After consulting the MSDN documentation, I learned that this parameter disables the use of the Windows application log to record SQL Server events.

It turned out that the third-party tool had modified the startup parameters for that particular SQL Server instance, resulting in the exclusion of error messages from the application event log. This discovery solved the mystery and taught me something new.

Now, let me ask you, have you ever encountered a similar situation where non-default startup parameters were used in a production server? It’s always fascinating to learn about different configurations and their impact on the behavior of SQL Server.

Remember, error logging is a powerful tool that can provide valuable insights into the health and performance of your SQL Server environment. Make sure to leverage this feature to its fullest potential.

That’s all for today’s blog post. I hope you found this information helpful. Stay tuned for more articles on SQL Server concepts and best practices.