Try the above sequence again and put a long delay(I used 5 minutes) between the 1st step( sp_getapplock ) and the last two steps. SQL Azure doesn't guarantee that the session is continous. If done "quickly" this will work as expected. SELECT APPLOCK_MODE('public', 'ALockTest', 'session') Įxec sp_releaseapplock 'ALockTest', 'session'
Take for example the use of the SQL Server application lock facility. And this can have a subtle effect on transaction and locking features of traditional SQL 2008 applications. Microsoft makes it very clear that connections to the Azure database are not 100% continous. But complex and "interesting" SQL Server applications that leverage advanced features require some close scruity and care when operating in the Cloud world. My initial impressions of the platform are positive. I'm working with a complex database and seeing how easy it is to port the application to SQL Azure. These constructs are still popular and appropriate in some cases. Return SQL 2005 and above you should consider using TRY-CATCH for all Insert-Update-Delete SQL operations. You must grab both at the same time or you’ll get the wrong value in the 2nd variable. Return the proper way to check for row counts and error codes. Here are some rewrites of the above examples: Return the check resets the error condition and returns 0. This is also a problem when you introduce constructs that have IF conditions. What will always(99%) get reported is a SUCCESS value of Zero (0).īecause ONLY maintains the condition of the “Last” SQL statement executed. The intent is rollback an open transaction and report the error number encountered to the the caller of the procedure. Return this work the way the original author expected? NO. I found this pattern in SQL Stored Procedures for error checking at a client. BUT make sure you understand how this works and fix those older legacy TSQL constructs that may have problems. Even with the advent of SQL 2005's TRY-CATCH feature you may still find this in old T-SQL or it might be the best fit for some applications. SQL 2000 error checking with and is still in use in many applications.
0 kommentar(er)
