January 5, 2017 at 7:12 am
there is a condition that is using in Error block
IF @ID IN ('Employee Update','Employee Insert','Employee variable')
BEGIN
Close Empcursor
Deallocate Empcursor
END
What it meant by this above condition?
January 5, 2017 at 10:44 am
It would appear the @ID contains certain user roles that are required to conditionally open a cursor somewhere else in the code. When an error occurs for other user roles that didn't open the cursor, the code to close and deallocate a cursor would fail because the cursor isn't open. So it's an offhand test to see if the cursor is open and then to close it if it is.
I damned sure wouldn't do it this way. I'd test the cursor directly to see if it were open. Can't answer how because I don't use cursors except to show how bad they are. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 5, 2017 at 11:18 am
I try to minimize the amount of complexity within the CATCH block of an error handler. According to MSDN there is no technical reason to explicitly close or deallocate a locally declared cursor, it will be deallocated when the procedure exits and the cursor falls out of scope. However, attempting to close a cursor that isn't open or deallocate a cursor that hasn't yet been declared will raise yet another error.
.. A cursor variable does not have to be explicitly deallocated. The variable is implicitly deallocated when it goes out of scope. ..
https://msdn.microsoft.com/en-us/library/ms188782.aspx
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 5, 2017 at 5:39 pm
Eric M Russell (1/5/2017)
I try to minimize the amount of complexity within the CATCH block of an error handler. According to MSDN there is no technical reason to explicitly close or deallocate a locally declared cursor, it will be deallocated when the procedure exits and the cursor falls out of scope. However, attempting to close a cursor that isn't open or deallocate a cursor that hasn't yet been declared will raise yet another error... A cursor variable does not have to be explicitly deallocated. The variable is implicitly deallocated when it goes out of scope. ..
I wonder if that's still true when some form of connection pooling is in place.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply