Wenn man bei Datenbanken komplexere Verarbeitungen durchführen muss, kommt man meist um die Verwendung eines cursors nicht herum. Doch jeder, der schon mal einen cursor verwendet hat kennt bestimmt das Problem: Das Statement zum Sammeln der Daten ist geschrieben und funktioniert, die Ausführung dauert nur wenige Sekunden. Jetzt noch den cursor aufsetzen und den Durchlauf testen. Und merkwürdigerweise dauert dasselbe Statement mit einem Cursor wesentlich länger – der Faktor 100 ist hier keine Seltenheit.

declare @custid t_d_id
declare @name varchar(255)
declare @firstname varchar (255)

declare c cursor for 
	select cu.r_customerid, t_lastname, t_firstname
	from [sql-uptime-sht].uptimedata.dbo.customer cu
open c
fetch next from c into @custid, @name, @firstname
while @@fetch_status = 0 begin
	print @custid
	fetch next from c into @custid, @name, @firstname
end
close c
deallocate c

 Langsame Verarbeitung des cursors

Das liegt daran, dass der Standardcursortyp ein dynamischer cursor ist. D.h. der SQL-Server prüft die Bedingungen bei jedem fetch-Aufruf und das zieht die Performance so deutlich nach unten.

Du willst feststellen, in welchen Tabellen auf eine Tabelle per Fremdschlüssel verwiesen wird und es gibt kein Datenmodell? Du fängst an, in den Systemtabellen zu suchen und Dir ein kompliziertes Statement aufzubauen? HALT! Das musst Du nicht. Ganz einfach geht es mit

 exec sp_fkeys <TABLENAME>
Es werden alle wichtigen Informationen zu den Fremdschlüsselbeziehungen angezeigt. Tolle Sache.

Weil ich es mir nicht merken kann und immer mal wieder danach suche. Mit folgendem Codeschnipsel kann man die Version des SQL-Servers auslesen:

SELECT @@Version

Das Statement steht ab der SQL-Server Version 2005 zur Verfügung.

Jedes Mal, wenn ich es brauche, suche ich danach, deshalb hier als Gedankenstütze. Mit dem folgenden Konstrukt kann man aus drei Werten für Jahr, Monat und Tag in SQL ein gültiges Datum generieren (MS SQL Server):

select cast(rtrim(jahr * 10000 + monat * 100 + tag) as datetime) as Datum from Tabelle