My talk on error handling in SQL Server and clients starts in another hour. Error handling in SQL has been more of an art than a science in previous versions, and some folks just pass every error back to the client directly. With TRY-CATCH in Transact-SQL you don’t have to do “passthrough” error handling now, but its not as “remove @@ERROR, plug in TRY-CATCH” as people first thought. Some folks wondered how I could do over an hour on errors alone; there’s actually even more to it than that. I’m sure glad they have unit testing in Team System for DB Pros; it will sure get people past the “oh, that error will never happen” mentality. <\/P>
\n
The DLINQ BOF last night was amazingly well attended. I’m surprised that there were very few “this should all be done in stored procedures” afficianados in attendence. It would make things more interesting if DLINQ worked in SQLCLR. Hmmm… Then this would be IN stored procedures.<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"
My talk on error handling in SQL Server and clients starts in another hour. Error handling in SQL has been more of an art than a science in previous versions, and some folks just pass every error back to the client directly. With TRY-CATCH in Transact-SQL you don’t have to do “passthrough” error handling now, […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-851","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"\n