Spalte hat den Wert Null und lässt sich nicht updaten

[Walter Landwehr]

ISNULL kennt Firebird nicht. Ich denke ich muss nach dem einfügen der Spalte den Wert auf 0 setzten.

[Neutral General]

Zitat von Walter Landwehr:

ISNULL kennt Firebird nicht. Ich denke ich muss nach dem einfügen der Spalte den Wert auf 0 setzten.

Wie himitsu schon gesagt hat: coalesce ist was du brauchst:

Code:

update TBL_MANDANT set MAILANZAHL = coalesce(MAILANZAHL, 0) + 1

[Walter Landwehr]

Dank himitsu,

das funktioniert.

update TBL_MANDANT set MAILANZAHL = COALESCE(MAILANZAHL, 0) + 1

[mkinzler]

NULLIF, COLAESCE,

IIF( <Spalte> is Null, 1, <Spalte> = <Spalte> +1)

SQL-Code:

case <Spalte>
  when null then 1
  else <Spalte> = <Spalte> +1
end

[TigerLilly]

Nocheinmal: Wenn man seine Tabellen von Anfang an g´scheit definiert braucht es nachher keine komplizierten Kopfstände.

Merke: NULL <> 0

ISNULL, IIF, COALESCE, WHEN in Kombination mit NULL sind immer ein Zeichen für mangelhaftes Design.

[p80286]

@Walter
Warum ist "ANZAHLMAIL" NULL und nicht 0?

Du solltest (falls es möglich ist) einmal von NULL auf 0 umstellen (Default Wert?) und dann hast Du Ruhe. alles andere ist nur ein herumgedoktere an den Symptomen.

Gruß
K-H

[himitsu]

Zitat von p80286:

Du solltest (falls es möglich ist) einmal von NULL auf 0 umstellen (Default Wert?) und dann hast Du Ruhe. alles andere ist nur ein herumgedoktere an den Symptomen.

Ein DEFAULT ohne das zugehörende NOT NULL wird nicht das Problem lösen, denn der Default greift nur, wenn die Spalte nicht geschrieben wird (nicht im INSERT drin steht, bzw. nicht explizit als "DEFAULT" zugewiesen wurde),
aber wenn jemand direkt/explizit ein NULL an das Feld übergibt, dann würde das auch so gespeichert.

Nein, per se ist die Definition NULL = Nichts und Wert>0 = etwas nicht falsch und könnte für "schnelle" Filter/Suchen/Joins auch so gewollt sein.
Aber ja, Anzahl = 0 statt NULL für Nichts ist ebenfalls nicht falsch.
Beides ist je nach Gutdünken "richtig".

[jobo]

Zitat von TigerLilly:

ISNULL, IIF, COALESCE, WHEN in Kombination mit NULL sind immer ein Zeichen für mangelhaftes Design.

Nein, bitte! Diese Aussage ist viel zu pauschal. Was soll ein Neuling damit anfangen?
ISNULL() ist genau in Kombination mit einem Nullwert sinnvoll, sogar dafür gemacht.

Aber vielleicht arbeiten die führenden DB Anbieter bereits daran, ihre Funktionsreferenzen umzugestalten:
"Wenn mal etwas schief gegangen ist"/Eigentlich verboten, aber ohne geht's halt nicht.


Left joins bspw. produzieren auf geradezu penetrante Art und Weise leere, undefnierte Werte (NULL) in den Ergebnisspalten, mal als Beispiel. Es ist vollkommen legitim, sogar notwendig, mit Hilfe der genannten Funktionen solche Resultate abzufragen/abzufangen.
Undefiniert ist halt undefiniert, wo's herkommt ist eine andere Frage, wie man's anpackt wurde ja richtig geschildert.

Man muss an der Stelle einfach pingelig sein und Grundlagen lernen. Muss man ja (gerade)in Delphi selbst auch.

[p80286]

Zitat von jobo:

Zitat von TigerLilly:

ISNULL, IIF, COALESCE, WHEN in Kombination mit NULL sind immer ein Zeichen für mangelhaftes Design.

Nein, bitte! Diese Aussage ist viel zu pauschal. Was soll ein Neuling damit anfangen?
ISNULL() ist genau in Kombination mit einem Nullwert sinnvoll, sogar dafür gemacht.

Entschuldige, aber Deine Formulierung ist mißverständlich. das Datenbank-NULL ist gleichbedeutend mit "Nix,Niente,dat jibbet nich" (nicht vorhanden!). Währen "Null" gerne mit "0" gleichgesetzt wird, was in der vorliegenden Tabelle wohl der Fall gewesen ist (nur meine Vermutung).

Gruß
K-H

[jobo]

Zitat von p80286:

..
Entschuldige, aber Deine Formulierung ist mißverständlich. das Datenbank-NULL ist gleichbedeutend mit "Nix,Niente,dat jibbet nich" (nicht vorhanden!). Währen "Null" gerne mit "0" gleichgesetzt wird, ..

Ja, richtig, wer Pingeligkeit verlangt, sollte das auch selbst einhalten, Präzisierung:
ISNULL() ist genau in Kombination mit einem NULL-Wert sinnvoll, sogar dafür gemacht.

Und dieser Hinweis ist natürlich auch wichtig,

Zitat von himitsu:

..Ein DEFAULT ohne das zugehörende NOT NULL wird nicht das Problem lösen..

allerdings ebenfalls missverständlich. "das zugehörende NOT NULL" würde in diesem Fall hier (Thread) da"zugehören" und die Sache wasserdicht machen, in vielen anderen Fällen sicher auch. Es ist aber nicht per se "zugehörend" zur DEFAULT Angabe und damit ebenfalls zu pauschal formuliert.

DEFAULT Angabe, NOT NULL Constraint sowie beliebige andere Spalten-Constraints sind beides optionale Angaben.
Was eben keineswegs bedeutet, dass es eine Sache für Pedanten oder Kosmetik Freaks ist.

Das Wichtige an diesen Dingen ist m.E., dass man mit ein paar Wörtchen mehr im Datenmodell ziemlich haargenau festlegen kann, wie die Sache laufen soll und sich damit oftmals eine Menge Code, Fehlerbehandlung und vor allem auch Fehlersuche erspart.

Um Einwänden vorzugreifen:
Auch ein sinnvoller, richtiger, wichtiger Datenbank Constraint ändert natürlich nichts daran, dass ein (häßlicher) Fehler auftaucht, wenn der Konstraint verletzt wird. Und das muss natürlich behandelt werden. Diese Behandlung kann aber ziemlich pauschal erfolgen, sinngemäß ungefähr "Der Meister hat bestimmt, dass diese Eingaben unzulässig sind". Das passt immer, wenn man sich (richtige) Gedanken über das Datenmodell gemacht und diese umgesetzt hat.

Noch mehr Blabla
Der entscheidende Punkt ist dabei, dass das Datenmodell per Definition für Datenkonsistenz sorgen soll. Demnach spart man sich in Folge die mühsame Suche und oder Bereinigung falscher Daten und ebenso Programmcode, der das "überwacht". (auch Anlass dieses Threads)
Das gilt dann immer, auch in jeglicher Situation, in der Datenmanipulation jenseits der Anwendung erfolgt, durch Import von Fremddaten, administrative DML, heterogene Clients (bswp. auch Versionswechsel des eigenen Programms)
Ergebnis: Meine Business Logik, die Reports, die Dashboards stimmen immer. Fall-basierter Code läuft niemals in undefinierte Bereiche.

Das ist allerdings eine Betrachtungsweise, die nur greift, wenn ich mich im Rahmen eines Client/Server Konzepts bewege. Werden separate Persistenzschichten genutzt, verlagert sich die Hoheit über die Datenkonsistenz (und das gesamte Modell) in diese Schicht.