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.

Bei uns im Projekt ist es zu einem geflügelten Ausspruch geworden, wenn sich jemand über einen anderen ärgert und seinem Ärger Luft macht: „Gib mir Tiernamen“. Da wir uns jetzt schon seit 16 Jahren kennen entspannt das die Lage meistens schnell.

Ob der Spamversender davon etwas weiß kann ich nicht sagen, aber die Anrede ist ja auch kein Tiername. In Zeiten immer schwerer zu erkennenden Spammails ragt diese Mail aus meinem Postfach schon ziemlich heraus. Schon die Anrede disqualifiziert die Mail als ernstzunehmende Nachricht.

Namen

Da ist James Kross schon eine gutes Stück weiter.

Von einem Kunden erreicht mich ein Hilferuf. Er will einen Report anzeigen und bekommt einen Fehler. Wie üblich sind die Rahmenbedingungen nicht genauer genannt und ich versuche erstmal den Fehler nachzustellen. Fehlanzeige. Der Report wird angezeigt, ohne Fehlermeldung und ohne Murren seitens der Software. Eine telefonische Nachfrage beim Kunden bestätigt auch dort ist das so, außer bei einem speziellen Report bzw. bei der Auswahl eines bestimmten Produkts.

Mit dieser Information komme ich weiter und kann den Fehler nachstellen. Alles deutet auf einen Stapelüberlauf wegen einer Endlosschleife hin. Daran kann eigentlich nur der Inhalt der Felder verantwortlich sein und als ich mir die Beschreibungen, die in HTML gespeichert wird, ansehe kann ich schnell ein strukturelles Problem erkennen. Hier scheint etwas mit der HTML-Struktur durcheinander geraten zu sein. Nach der Bereinigung der Daten kann dann auch der Report wieder angezeigt werden.

HTML

Die eigentliche Ursache bleibt unklar, ich vermute aber einen Zusammenhang mit einer nicht ganz unbekannten Bürosoftware bei der die HTML-Struktur hin und wieder ebenfalls etwas merkwürdig gestaltet wird.

Gestern hatte ich großes Betriebszugehörigkeitsjubiläum. Vermutlich hätte ich gar nicht daran gedacht, wenn ein Kollege mich nicht angesprochen hätte. Irgendjemand aus der Administration muss es in unserem Urlaubskalender vermerkt haben. Doch bis auf den Eintrag in dem Onlinekalender hatte mein Jubiläum keinerlei Auswirkungen. Es gab keinen Händedruck, keine persönliche Ansprache und auch kein Geschenk – muss ja auch nicht.

Ich bin jetzt schon unglaubliche 16 Jahre hier im Unternehmen. Seit 16 Jahren pendele ich, mit Ausnahme  von einigen Homeofficetagen, Urlaub, Feiertagen oder Kundenbesuchen also täglich nach Kassel. Wo ich wohl inzwischen wäre, wenn ich mich die Kilometeranzahl von der Erde weg bewegt hätte? Vermutlich immer noch recht nach an Mutter Erde.

Blicke ich auf die 16 Jahre zurück,

Wenn man mit einem Programm die Registrierung auslesen muss, sollte man besonders bei 64-Bit Systemen aufpassen. Öffnet man das Tool regedit bekommt man die  64-Bit-Ansicht der Windows-Registry angezeigt. Soweit so gut.

Öffnet man die Registry aber aus dem Code heraus, kommt es darauf an, wie man das Executable Kompiliert hat. Mit der Einstellung X86 öffnet man die Registry in der 32-Bit-Ansicht. Mit der Einstellung X64 öffnet man die Registry in der 64-Bit-Ansicht. Bei AnyCPU kommt es noch auf die Einstellung unter Prefer 32-Bit an. Richtig: ist hier ein Haken gesetzt, wird die 32-Bit, sonst die 64-Bit-Ansicht geöffnet. Klingt ziemlich verworren? Ist es auch.

Den Abhängigkeiten über das Platform-Target kann man dadurch umgehen, dass man beim Öffnen der Registrierung angibt, in welcher Ansicht man die Registry öffnen will. Und das geht so:

//needed for the registry access
using Microsoft.Win32;
//search in current user
RegistryKey currentUser64 = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry64);						
RegistryKey currentUser32 = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry32);						

 Nützlich kann es bei dieser Verarbeitung noch sein, dass man nach der Architektur des Betriebssystems unterscheidet. Dazu kann der folgende Einzeiler verwendet werden: