http://www.sqlskills.com/blogs/joe/hunting-down-the-origins-of-fetch-api_cursor-and-sp_cursorfetch/ This returns: FETCH API_CURSOR0000000000000004 Didn’t help. So what about other DMVs? You eventually find a reference to the sys.dm_exec_cursors DMV and see it can tell you about open cursors, their properties and associated SQL handle. But you're not sure the SQL Handle will be any help because it hasn't been helpful with the other DMVs:
SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text FROM sys.dm_exec_cursors (53) c CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t
From the results we see the properties of the cursor (using scroll locks) and we also see when it was created – and we see the original query text (unlike the cryptic FETCH API_CURSOR business or the sp_cursorfetch). We see it was a SELECT * FROM dbo.FactResellerSales. Now this isn’t to say that SQL Profiler wouldn’t have helped in this situation – but in this case the cursor was defined before the developers captured the downstream activity. If they had been tracing it sooner, you might have seen something like this (and then see it followed by sp_cursorfetch):
declare @p1 int set @p1=180150003 declare @p3 int set @p3=2 declare @p4 int set @p4=2 declare @p5 int set @p5=-1 exec sp_cursoropen @p1 output,N'SELECT * FROM dbo.FactResellerSales',@p3 output,@p4 output,@p5 output select @p1, @p3, @p4, @p5
But in a situation where you’re reacting to an incident (fox has already left the henhouse, so to speak), chances are you weren’t tracing this activity. And if that’s the case, you’ve now found one reason to use sys.dm_exec_cursors if you didn’t already have one.
