NULL-Werte in DropDownList

Eine DropDownList soll dynamisch mit Inhalten aus einer Tabelle (B) gefüllt werden. Der ausgewählte Index soll als Schlüssel in Tabelle (A) eingefügt werden.

Dies realisiert man relativ einfach durch Datenbindung. Dabei wird der SelectedValue des DropDownfeldes mit der Spalte in Tabelle (A) verknüpft:

Als Datenquelle für die Liste im DropDownList wird eine entsprechende DataSource gewählt:

Und schon klappts – Naja fast.

Will man nämlich auch „keinen Wert“ auswählen hat man ein kleines Problem. Denn der Wert „nichts“ (oder NULL) ist in der Tabelle (B) nicht enthalten. Versucht man nun einen Datensatz anzuzeigen, der in Tabelle (A) im Fremdschlüsselfeld den Wert NULL enthält, bekommt man folgenden Fehler:

Da in Tabelle (B) der Wert NULL nicht vorhanden ist, weiß das Programm nicht, welchen Wert es in der DropDownList anzeigen soll (weil es nicht in der Elementliste vorhanden ist). Um dennoch NULL-Werte (also nix) auswählen zu können ist folgende simple Erweiterung des DropDownList erforderlich:

Die Eigenschaft „AppendDataBoundItems“ des DropDownList wird auf True gesetzt. Damit „mischt“ man die statisch eingegebenen Einträge mit denen, die aus der DataSource kommen.

Für den NULL-Wert fügt man nun unter ITEMS einen Leer-Wert hinzu – und fertig ist das Ganze.

Nun besteht die Liste im DropDownList aus den Werten aus der Datenbank und einem einzelnen leeren Wert, den wir manuell hinzugefügt haben.

UNIQUE CONSTRAINT ist nicht CHECK CONSTRAINT

In einer Datenbanktabelle will man manchmal sicherstellen, daß in einer Spalte Werte nicht mehrfach vorkommen, sie also „unique“ sind. Bei einem Primärschlüssel wird dies automatisch durch Definition der Spalte als Primärschlüssel sichergestellt – aber es gibt Fälle, in denen man zwar die Einzigartigkeit der Werte sicherstellen will, aber keinen Primärschlüssel benötigt oder haben mag.

Für diese Fälle gibt es die UNIQUE CONSTRAINT. Will man die jedoch im „Microsoft SQL Server Management Studio (Express)“ definieren, stößt man auf ein kleines Problem: Nirgendwo findet man die Möglichkeit diese UNIQUE CONSTRAINT festzulegen.

Zwar gibt es CONSTRAINTS, doch dahinter verbergen sich sogenannte CHECK CONSTRAINTS. Erst nach einigem herumgesuche wird einem klar: CHECK CONSTRAINTS sind nicht gleich UNIQUE CONSTRAINTS.

Doch des Rätsels Lösung ist – wenn man’s weiß – ganz einfach. CHECK CONSTRAINTS prüfen, ob die gespeicherten Werte bestimmte Bedingungen erfüllen. Also ob z.B. eine Eingabe mindestens aus x Zeichen besteht. Es wird hier also etwas „gecheckt“.

UNIQUE CONSTRAINTS dagegen sind eigentlich so was wie ein Index – und verstecken sich daher auch unter dem Menüpunkt „INDEXES“. Und das ist die erste Gemeinheit: ein UNIQUE CONSTRAINT ist ein Index – kein CONSTRAINT.

Die zweite Gemeinheit: Man kann bei einem Index festlegen, daß er „UNIQUE“ ist. Aber: damit wird es noch lange kein UNIQUE CONSTRAINT. Erst wenn man den Type des Index auf „Unique Key“ setzt – dann hat man endlich eine UNIQUE CONSTRAINT.

UNIQUE CONSTRAINT = UNIQUE KEY INDEX

Es sei noch erwähnt, daß man obige Maske erreicht, wenn man auf der Tabelle rechts klickt und den Punkt „MODIFY“ auswählt. Dann klickt man in der Symbolleiste den Punkt „Manage Indexes an Keys“ an.

Das Ganze geht nicht, wenn man einen bereits bestehenden Index auswählt und sich die Properties anzeigen läßt. Hier gibt es zwar auch einen „Type“ (nämlich Index Type) – doch der bedeutet was anderes.

Falsche Fährte: Index Type ist nicht der Type des Index!