NULL ist ein sehr eigenwillige Nichts. Es gibt extra Ausdrücke wie ISNULL, IS NULL dafür um es abzufragen. Man kann also mit einem einfachen Vergleich "gesperrt <> 1" nicht arbeiten. daher entweder das IS NULL berücksichtigen oder einen Default setzen.
Mir hat es geholfen, NULL als 'undefiniert' oder als '(noch) nicht festgelegt' zu denken. Dann wird recht klar, dass eine Abfrage wie 'gesperrt <> 1' einfach keine Aussage über ein Feld mit dem Inhalt NULL machen kann - es ist schlichtweg (noch) kein Wert bekannt. Da die Frage, ob der Wert <> 1 ist, also (noch) nicht beantwortet werden kann, tauchen die entsprechenden Datensätze in der Ergebnismenge nicht auf.
Danke, ich habe es jetzt so gelöst, daß ich die Tabellendefinition auf gesperrt not null default 0 umgestellt habe. Jetzt klappt das ohne Verrenkungen.
fliegermichl hat geschrieben: Mi 11. Jan 2023, 18:50
Danke, ich habe es jetzt so gelöst, daß ich die Tabellendefinition auf gesperrt not null default 0 umgestellt habe. Jetzt klappt das ohne Verrenkungen.
Ja ja, eine binäre Logik, die aber trinär ist, ist schon eine gewisse Herausforderung
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
fliegermichl hat geschrieben: Mi 11. Jan 2023, 18:50
Danke, ich habe es jetzt so gelöst, daß ich die Tabellendefinition auf gesperrt not null default 0 umgestellt habe. Jetzt klappt das ohne Verrenkungen.
Das klappt jetzt sicher.
Ich verwende für derartige Flag-Felder meistens Datumsfelder, dann habe ich nicht nur die Information ob zB ein Kontakt gesperrt wurde sondern auch wann. Wenns nicht allzu genau sein muss kann man in die Millisekunden auch noch das "wer" reinkodieren. Oder ein zusätzliches Feld bzw eine History bemühen.
charlytango hat geschrieben: Mi 11. Jan 2023, 20:37
fliegermichl hat geschrieben: Mi 11. Jan 2023, 18:50
Danke, ich habe es jetzt so gelöst, daß ich die Tabellendefinition auf gesperrt not null default 0 umgestellt habe. Jetzt klappt das ohne Verrenkungen.
Das klappt jetzt sicher.
Ich verwende für derartige Flag-Felder meistens Datumsfelder, dann habe ich nicht nur die Information ob zB ein Kontakt gesperrt wurde sondern auch wann. Wenns nicht allzu genau sein muss kann man in die Millisekunden auch noch das "wer" reinkodieren. Oder ein zusätzliches Feld bzw eine History bemühen.
Hm, ist ansich eine gute Idee. Wie sieht dann aber der select aus, wenn ich wissen will, wer hat wann welchen Kontakt gesperrt
DROP TABLE IF EXISTS test;
CREATE TABLE test (
id int NOT NULL AUTO_INCREMENT,
dt datetime(6),
PRIMARY KEY (id)
);
INSERT INTO test (dt) VALUES (NOW()), (NOW(6));
INSERT INTO test (dt) VALUES (CAST('2009-12-31 23:59:59.998877' as DATETIME(6)));
SELECT * FROM test;
SELECT * FROM test WHERE MICROSECOND(dt)=998877;
SELECT * FROM test WHERE MICROSECOND(dt)=998877 AND DATE(dt)='2009-12-31';
six1 hat geschrieben: Fr 13. Jan 2023, 13:25
Naja, in der Tabelle wird ja noch Platz für einen INT sein, um den Sperr-User zu identifizieren
wenn man das wissen will, dann ist es IMHO besser, zusätzlich eine Protokolldatei zu führen.
Nach dem Motto:
- Timestamp
- User
- Tabelle
- Aktion (angelegt, geändert, gesperrt, entsperrt, gelöscht etc.)
Vbxler hat geschrieben: Sa 14. Jan 2023, 14:12
Es gibt bei den verschiedenen RDMS meist eine Möglichkeit bei
einem NULL in der Zelle einen Ersatzwert in der Abfrage zu liefern.
Deswegen habe ich schon auf ISNULL verwiesen, was für den MSSQL funktioniert. Das verhalten bei NULL ist vom SQL-Server abhängig, auch welcher Befehl da etwas bewirkt. Das zeigt zum Beispiel hier MS SQL Server <> Interbase.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Das war auch keine Kritik, sondern der Hinweis daß solche Feinheiten bereits unterschiedlich sein können. Weil derjenige der das versucht, vielleicht den falschen Server oder manchmal auch nur eine Version des Servers, die das nicht kann.
Für mich persönlich war das klar, weil der Server dabei gestanden ist, allerdings wird am MS SQL etwas anderes verwendet. Wie SQlite oder MariaDB das handhaben weiß ich aktuell gar nicht. Es könnte das Verhalten aber auch noch von den Komponenten zusätzlich abhängen, zumindest ist mir das gerade eingefallen. Kompliziert halt.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
af0815 hat geschrieben: So 15. Jan 2023, 16:29
Kompliziert halt.
Aber vermeidbar wenn man sich der grundlegenden Problematik bewusst ist.
Dann ist eben das Tabellendesign binär statt trinär. Wichtig ist nur zu wissen was man sich mit welcher Variante (oder auch Kundenvorgabe) einbrockt und wie man damit umgehen will.