MS-Access 2016: VARCHAR mit Inhalt "" oder NULL

[berens]

Hallo zusammen,
ich habe ein Problem mit einer Abfrage in meiner Anwendung. Ich konnte es soweit eingrenzen, dass das Problem nicht innerhalb von meinem Programm oder Delphi besteht, sondern alleine in der MS-Datenbank (.mdb), die wir verwenden [müssen]:

Ich benötige alle Zeilen einer Tabelle, bei denen [der String in] MyField leer ist. MyField ist ein String, hier konkret in dieser .mdb-Datei ein "Kurzer Text" (via SQ-Statement VARCHAR(255) angelegt). Der Standardwert soll leer sein, also "".

Über die SuFu hier im Forum konnte ich schon ermitteln, dass es für eine vergleichbare Abfrage ein riesen Unterschied ist, ob ein Feld den "Systemwert" NULL gespeichert hat, oder den leeren String "". Eine Abfrage, für Zeilen in denen bei MyField kein sichtbarer Text drinnen steht, scheint also nicht so ganz trivial.

Theoretisch müsste diese Abfrage immer die richtigen Werte liefern:

Code:

SELECT *
FROM Tabelle1
WHERE (((Myfield) Is Null)) or (MyField="");

Aber Access verhält sich heute sehr merkwürdig und ich traue dem Braten nicht. Auch besteht natürlich die Gefahr, dass dieser Filter an mehreren Stellen im Quelltext benötigt wird, und bei komplexen Ausdrücken nun doch irgendwas schief läuft, wenn ich da einfach die alte Abfrage MyField <> "" durch die o.g. ersetze...

Für vergleichbare Fälle lasse ich beim Programmstart eine Logikprüfung über meine Tabellen laufen (z.B. dass eine Warnmeldung ausgegeben wird, sollte der Zeitpunkt für das Ende ein Termins einmal vor dem Startzeitpunkt liegen etc.), wo ich nun auch gerne alle Einträge mit NULL in MyField auf "" setzen würde (=leeren String, aber halt nicht NULL).

Meine Abfrage dafür lautet.

Code:

UPDATE Tabelle1 SET MyField = ""
WHERE (MyField Is Null);

Diese habe ich zu Testzwecken in Access direkt ausgeführt und keine Fehlermeldung erhalten.
Leider gibt die Abfrage

Code:

SELECT *
FROM Tabelle1
WHERE (Myfield Is Null)

nun immer noch Datensätze zurück, die vorherige Änderungsabfrage war also scheinbar nicht erfolgreich.

Was mache ich falsch, was muss ich anders machen?

Kann ich evtl. die Einstellungen für die Spalte MyField (siehe Anhang) verändern, dass NULL automatisch als identisch mit "" interpretiert wird?
Scheinbar kann der Wert "Leere Zeichenfolge" angeben, ob eine leere Zeichenfolge gültig ist (Leerer String oder NULL???). Ich kann die verlinkte Dokumentation aber nicht soweit interpretieren, ob -wenn ich diesen Wert auf "Nein" stelle, dann alles NULL als "" interpretiert wird? Es gibt noch die Eigenschaft "Required" (Eingabe erforderlich), aber ich denke fast, diese Werte spielen nur innerhalb der Access-GUI eine Rolle?

Vielen Dank für Tips!

[stifflersmom]

Kennt Access coalesce?

Dann wäre das eine Möglicghekit, dei Abfrage sicher auszuführen:

Code:

SELECT *
FROM Tabelle1
WHERE COALESCE(Myfield,'') ="";

[berens]

Nope.

Zitat:

Undefinierte Funktion "COALESCE" in Ausdruck.

[stifflersmom]

Hier wird NZ als Möglichkeit beschrieben:
https://www.techonthenet.com/access/...dvanced/nz.php

Dann müsste das so gehen:

Code:

SELECT *
FROM Tabelle1
WHERE Nz(Myfield,'') ="";

[himitsu]

Sind im Access " und ' wirklich das Selbe?


Access hat aber nicht zufällig was drin, dass aus Leerstrings ein NULL macht, bzw. andersrum?

PS: In dem Bild steht bei Default/Standardwert was von "".
Aber eigentlich dachte ich der Default wird in allen DBMS nur dann verwendet, wenn man ein INSERT ausführt, und dabei dieses Feld nicht übergibt.

In PgDAC gibt es z.B. eine Option, die sowas bei einem Post macht. (zwar werden hier nur im DataSet die TField im BeforePost auf NULL gesetzt und nicht bei einem direkten UPDATE-Statement), aber vielleicht gibt es im Access sowas auch direkt in der Datenbank.



Bei Required/Erforderlich = True sollte jede explizite Zuweisung von NULL (und ein fehlendes DEFAULT beim INSERT) zu einer Fehlermeldung führen.
Wenn es nie NULL sein soll, wieso aktivierst du das dann nicht?

[berens]

Danke, @stifflersmom, das liefert [auch?] die Zeilen zurück, die NULL sind. Die Beschreibung auf der verlinkten Website ist schlüssig.

Code:

SELECT *
FROM Tabelle1
WHERE Nz(Myfield,'') ="";

Leider kann ich mit Access gerade keinen Eintrag erzeugen, der nur leeren Text drinnen hat, aber kein Null, aber ich hoffe einfach mal, wenn das NZ von vielen Leuten verwendet wird, dass es da auch zuverlässig arbeitet . Danke soweit.

@himitsu
> In dem Bild steht bei Default/Standardwert was von "".
Ja, das hat mich auch gewundert. Natürlich steht in meinem Quelltext:
q.SQL.Add('ALTER TABLE Tabelle1 ADD Myfield VARCHAR(255) DEFAULT "";'); Aber dass der das soooo wörtlich nimmt...
Es kann natürlich auch sein, dass die Zeilen bei/nach der Anpassung der Tabelle einmalig einen "leeren String" haben (z.B. \#0 oder wie auch immer das Zeichen dafür ist), und beim Abspeichern durch mein Programm, wenn der Wert "" dann über eine interne Routine den o.g. \#0 bekommen oder so.

> Wenn es nie NULL sein soll, wieso aktivierst du das dann nicht?
Eine fachlich richtige Antwort kann ich die hierfür nicht geben, dafür weiß ich, das Du ein x-Mal besserer Programmierer bist als ich; hast mir ja schon oft genug geholfen. Es gibt hier nur die "ehrliche" Antwort: aus Faulheit UND Unwissenheit. Long story short, bevor ich hier zu weit abdrifte: Ich habe mehrere Module die Einträge in dieser "Tabelle1" anlegen können. Diese sind nicht miteinander verkoppelt - was auch so bleiben soll(te). Wenn Modul1 -was den Wert "MyField" nicht kennt- nun eine Zeile schreibt, und NULL nicht mehr zugelassen ist, gibt es -denke ich mal- beim Post 'ne Exception. Modul1 kennt aber das Feld nicht. Ich müsste alle Module anpassen um (zusätzlich) ein Feld zu initialisieren, was in diesen Modulen 0% Relevanz hat. Mir als Mensch ist das echt sowas von egal ob da NULL oder "" drin steht, nur die Abfrage muss mir zuverlässig zurückgeben "ob da in dem Feld menschenlesbare Zeichen drinen sind, oder nicht". Hier ist die angepasste Abfrage von @stifflersmom einfacher an 7-8 Stellen einzupflegen, als in jedem Modul -imo "unnötigerweise"- das Feld "MyField" jedes Mal mit abspeichern zu lassen, NUR damit es keine Exception gibt. Natürlich wäre dein vorgeschlagenes Verfahren das Richtige - ToDo-Liste und Terminierungen sagen aber: geht nicht, nicht die "einfache" Lösung. Nicht professionell, aber ich kann mich leider nicht verreißen... Und ja: da muss von Grund auf eine andere Struktur rein. Stichwort: Historisch gewachsen.

Ich hoffe, dass die NZ Funktion alles perfekt abdeckt, ich denke, damit komme ich für den Moment ausreichend weiter.
Vielen Dank allen Antwortern , Thema beendet.