Feld auf NULL setzen?

[Daniel Llin]

Hallo!
Ich habe eine Tabelle T mit einer Spalte s vom Typ int(11) in meiner mySQL-Datenbank.

Ich möchte nun für bestimmte Zeilen der Tabelle T den Wert von s auf NULL setzen.

So hab ichs probiert:

update T set s = NULL where <bla blub>

Leider wird der Wert so immer auf 0 und nicht auf NULL gesetzt!

Wo ist mein Denkfehler?!?

[robert.oh.]

Hallo,

Ich kenn mich mit mySQL nicht so gut aus, aber in MS SQL Server wuerde ich ueberpruefen, ob die Spalte 'nullable' ist, also NULL Werte zulaesst.

Der Command selbst scheint korrekt zu sein.

HTH

[max10]

Hallo

probier einmal:

update T set s = 'NULL' where <bla blub>

[Falk Prüfer]

Hallo Daniel,

deine SQL-Syntax ist korrekt! Ein set s = 'NULL' ist Unsinn und würde nur einen Konvertierungsfehler bringen, da versucht wird ein INT-Feld mit einem String zu belegen.
Ich würde eher überprüfen, ob die Tabelle mglws. einen Trigger besitzt, der automatisch NULL-Werte für dieses Feld auf 0 ändert.

Gruß Falk

[Daniel Llin]

Hm, der Fehler war ein bisschen blöde. Robert hat voll ins Schwarze getroffen: Die Spalte lies einfach keine NULL-Werte zu. Ich war einfach fest davon ausgegangen, dass das Datenbankschema schon richtig aufgesetzt war. Sorry.

Danke an Euch!

[Bernhard Geyer]

Hm, der Fehler war ein bisschen blöde. Robert hat voll ins Schwarze getroffen: Die Spalte lies einfach keine NULL-Werte zu. Ich war einfach fest davon ausgegangen, dass das Datenbankschema schon richtig aufgesetzt war. Sorry.

Und die von der Datenbank in diesem Fall (normalerweise) geworfene Fehlermeldung/Exception wurde im Programm verworfen?

[Falk Prüfer]

Hallo,

ich bin ja mittlerweile einiges von MySQL gewohnt, aber das ein NOT NULL Integerfeld beim Update auf NULL stillschweigend mit numerisch 0 belegt wird, anstatt das Update mit "#1048 - Column 'id' cannot be null" zu verweigern, das war mir auch neu. Aber es ist so, zumindest bei der getesteten 4.1
Die Exception für die NOT NULL Verletzung kommt nur beim Insert!

Das ist ja gruselig...

Gruß Falk

[Bernhard Geyer]

Das ist ja gruselig...

MySQL haut öfters mal riesige Bugs in Updates rein. 4.1.14 war so ein Fall (Varchars wurden als Blobs gemeldet)

Und Oracle macht es umgekehrt. Leere Strings werden nach NULL gewandelt.

[Falk Prüfer]

...Und Oracle macht es umgekehrt. Leere Strings werden nach NULL gewandelt.

Wobei ich dort etwas hin- und hergerissen bin ob ich das als Bug oder als Konsequenz bezeichnen soll. Da kommt es auf die Sicht des Betrachters an, was ein leerer String ist. Ist das Nichts, Leer, Null - dann hätte Oracle recht oder ist das Etwas mit Nichts drin, also quasi eben nicht undefiniert. Wo liegt der Unterschied für den Betrachter? [] [] - In welchem von den beiden Kästchen ist das NULL und wo der Leerstring drin? *gg*
Also doch eine "philosophische" Frage? Es gibt mit Sicherheit für beide Ansichten entsprechende "logische" Erklärungen.

Gruß Falk

[Bernhard Geyer]

Wo liegt der Unterschied für den Betrachter? [] [] - In welchem von den beiden Kästchen ist das NULL und wo der Leerstring drin? *gg*

Dann wenn man mehrer Primär/Fremdschlüsselfelder hat und einige davon leer sein können. Dann ist es mit Joins etwas schwierig ...

[Falk Prüfer]

Dann wenn man mehrer Primär/Fremdschlüsselfelder hat und einige davon leer sein können. Dann ist es mit Joins etwas schwierig ...

Ja aber doch nur dann, wenn ich noch zwischen Leer (NULL) und Leer (Leerstring) unterscheiden muß. Also mir fallen mehr Vorteile und die logischeren Erklärungen ein warum Leerstring = NULL sein sollte!
Wenn ich das mal auf die Praxis übertrage und mir einen User Vorstelle, der sich beschwert das er einen Datensatz nicht speichern kann und immer die Meldung kommt er muß bei "Name" etwas eintragen. Wenn der mir dann auf Nachfrage - Was er denn bei "Name" eingetragen hat - erklärt: "Na einen Leerstring!" Da wüßte ich nicht wofür ich ihn halten sollte und nach deiner Ansicht müßte ich ihm sogar recht geben.

Gruß Falk

[Bernhard Geyer]

Der Einwand ist berechtigt wenn das Programm nicht dafür sorgt das ein Leerstring eingetragen wird. Und bei unserem Programm wird das im DB-Layer sicher gestellt.