Question

This week our database on a SQL2014 SP2 CU11 server started throwing fatal errors (severity 20), on the FETCH statement of code, which could be reduced to:

DECLARE @dummy int
DECLARE CurName CURSOR LOCAL FOR
        SELECT TOP (1) t.id FROM dbo.t_table AS t;
OPEN CurName;

WHILE 1 = 1
BEGIN
    FETCH NEXT FROM CurName INTO @dummy;
    IF @@fetch_status <> 0 BREAK;
    PRINT @dummy
END;

DBCC CHECKTABLE and DBCC CHECKDB did not find any problem, a server restart did not help (and since it occured on multiple versions of the same database at the same time, it was very unlikely, that this was a database structur problem).

On a developement server with SQL2014 SP2 and only CU6 the same statements runs without problem (on a SQL2017 Server it works too).

The table

  • has around 4 mio rows
  • is partitioned by an integer column
  • has an clustered PK over two columns (the partition column plus a bigint)
  • has 25 indexes (I guess, I should clean up a little bit :-))
Was it helpful?

Solution

First solution: When I changed the CURSOR declaration to

DECLARE CurName CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY FOR ...

(or at least added the STATIC keyword), it runs fine.

Final solution: The table had a geometry and a geography column, which were dropped this weekend (together with the two corresponding spatial indexes).

Since this was the only change to this table, I decide to rebuild the clustered primary key index, which solved this problem.

It seems, that the SP2 CU11 in SQL2014 has a small bug in this special case, so maybe someone with a similar problem find this solution useful...

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top