Database Error Handling
SQL Server had a very simplistic error handling capability before SQL Server 2005 was released. The Global System Variable @@ERROR contained the value of any error occurring from the last statement. If no error it contained the value zero. For granular error trapping you had to test @@ERROR after each statement to assure all was well.
SQL Server 2005 introduced the Try/Catch syntax allowing multiple statements to be encapsulated into an error trappable unit of work. It also exposed more system variables providing information about the error being returned. Those variables are available in the Catch block.
My goal in the newsletter is not to provide detailed education. I introduce topics in order to get a dialog going with ideas and experiences from our readers at large. I intend to bring relevant topics to you for further study or research. So, feel free to dig in to find the best practices for error handling in your version of SQL.
Before I walk away from the topic altogether, let me drop the big bomb by asking the question, how much error trapping belongs in the database? I find that I frequently put error trapping in the database client as well as in the SQL code. Do you have any rule of thumb you find relevant? Are then any patterns or best practices you might recommend?
Drop me a line with your ideas to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Troubleshooting problems with connection to SQL Server 2008
In this article, you can find the description of SQL Server 2008 connection bugs and the information on how to resolve or work around these problems.
Featured White Paper(s)
THE SQL SERVER SECURITY THREAT — IT’S CLOSER THAN YOU THINK
Written by: Kevin Beaver Kevin Beaver, CISSP, is an independent information security consultant, author, expert witness an… (read more)