Sebastian K.s erste Begegnung mit Megan - einer Programmiererin in der firmeneigenen Abteilung für Datenüberprüfung - begann mit einer unschuldigen Frage: "Wie bekomme ich den ersten Wert aus einer Variable?"

Sebastian hatte keine Ahnung, was sie meinte und fragte genauer nach. Megans Code sah in etwa so aus:

iResult := agg_sum('rec-a',  0.11);
... entfernt ...
iResult := rlt_amtd(iAppNum) * 100;

Sie zeigte auf die erste Codezeile und fragte: "Hier speichere ich das Ergebnis der ersten Berechnung, und dann hier das der zweiten. Aber ich brauche beide für das Endergebnis. Wie bekomme ich also den ersten Wert zurück?"

Sebastian wusste nicht gleich, was er antworten sollte. Schließlich war Megan für die Entwicklung mehrerer Programme für die Datenüberprüfung zuständig - und dann sollte sie so eine grundlegende Frage stellen? Er antwortete freundlich: "Es sieht so aus, als ob deine "iResult"-Variable vom zweiten Aufruf überschrieben wird..."

Megan schien etwas verwirrt zu sein und fragte: "Wie kann ich das ändern?"

Sebastian wollte Megan nicht beleidigen und nahm daher nur zögernd die Tastatur an sich. Schließlich machte er eine kleine Änderung im Code.

iAggResult := agg_sum('rec-a',  0.11);
... snip ...
iRltResult := rlt_amtd(iAppNum) * 100;

"Oh," sagte sie, "Ich hätte nicht gedacht, dass das geht!"

Megan hatte nun ihren Programmierlehrer gefunden und fragte Sebastian, was sie mit einer speziellen SQL-Anfrage machen sollte. Sebastian kam vorbei, um zu sehen, worum es ging...

SELECT *
FROM
(
	SELECT * FROM APPL WHERE APPRCVD IS NOT NULL
	UNION
	SELECT * FROM APPL WHERE APPRCVD IS NULL
)

Offenbar wollte sie alle Datensätze, egal ob das Feld APPRCVD "null" ist oder nicht. Als Sebastian erklärte, dass die ganz einfach die "WHERE"-Klausel hätte weglassen können, antwortete sie: "Ich hätte nicht gedacht, dass das geht!"

In der nächsten Woche bat sie Sebastian erneut, zu ihr zu kommen und ihr bei ihrem neuesten Problem zu helfen: sie erhielt dauernd Fehlermeldungen, dass zu viele Cursors (Zeiger in SQL) offen seien. Wenn man den Code sieht, ist es recht offensichtlich, wieso.

open myCursor(Id);
fetch myCursor into vrow;
if myCursor%NOTFOUND then
	pReturnMsg := 'Anwendung nicht gefunden;
	return True;
end if;
close myCursor;

Sebastian erklärte daraufhin, dass es wichtig sei, Cursors immer nach der Verwendung zu schließen. "Aber ich mache es doch!" sagte Megan und zeigte auf die letzte Zeile. Sebastian erklärte dann weiters, dass "return True" sofort die Funktion beendet und nichts danach mehr ausführt. "Oh," antwortete Megan überrascht, "ich habe das nicht gewusst! Das würde einiges erklären. Ich hätte nicht gedacht, dass das geht!"

Im Verlauf der nächsten paar Monate erfuhr Sebastian recht schnell, dass "Ich hätte nicht gedacht, dass das geht!" Megans Lieblingsspruch war. Dank Sebastians Hilfen und Tipps stellte sie glücklicherweise immer weniger und weniger Fragen. Sie wurde schließlich so gut, dass sie sogar gebeten wurde, bei anderen Projekten mitzuhelfen.

Vorher war Megans Code in der Kategorie "Falsch-aber-meist-harmlos", aber der neue Code war eher "Falsch-und-verdammt-gefährlich". Beispielsweise hat sie eine Oracle-Forms-Anwendung entwickelt, in der keiner der Felder irgendeine Datenbankverbindung hatte. Alle eingegebenen Daten haben nie die Datenbank erreicht. Um diesen Bug zu entdecken und zu beheben, brauchte es zwei Monate.

Danach entwickelte sie eine andere Anwendung, die mehrere Tabellen mit einem Trigger ändern sollte. Das Problem war, dass sie die "WHERE"-Klausel in der "UPDATE"-Anfrage vergessen hatte. Jeder Datensatz in jeder Tabelle wurde geändert, wenn der Trigger aufgerufen wurde.

Nach zahlreichen Fiaskos und zerstörten Daten reagierte das Management endlich. Megan wurde zum Chef aller Entwickler der gesamten Abteilung befördert.

(Übersetzt von Andreas Moser)