Liebe Liste,
ich werde nicht Schlau aus dem Konzept mit den NULL-Werten in MySQL (in Zusammenarbeit mit OO).
In MySQL gibt es die Möglichkeit Spalten das Attribut "NOT NULL" zu geben oder die Möglichkeit von NULL zu erlauben. Im zweiten Fall sieht phpmyadmin NULL als Standard vor.
Wenn ich mit einem OpenOffice-Formular nun auf eine MySQL-Tabelle zugreifen will gibt es folgende Probleme:
1. Wenn ich die Tabellenspalten mit dem Attribut NOT NULL versehe meckert OpenOffice, wenn nicht alle TAbellenspalten auch im aktuellen Formular sind und gibt die Fehlermeldung aus: Spalte xyz darf nicht NULL sein.
2. Also Richte ich die Tabelle so ein, dass NULL-Werte erlaubt sind. Nun schreibt OpenOffice für alle Felder in die ich nicht explizit etwas reinschreibe NULL rein. (Bzw. macht das die Datenbank... da NULL als Standard vorgesehen ist???) -> wenn ich jetzt einen Datensatz, den ich gerade eingegeben habe per MySQL-Abfrage suchen will, gibt er mir den Datensatz dann nicht aus, wenn in der Abfrage Bspw. nach Name und Ort suche und der ORT NULL ist (weil im SQL-STatement "ort LIKE %%" steht. (Suchfunktion über Makro) Klar, laut MySQL Referenz müsste man IS NULL explizit angeben. Ich könnte nun alle SQL-Abfragen umbauen, damit auch nach NULL-Werten explizit gesucht wird, aber das erscheint mir zu umständlich.
Jetzt gibt es aber in OpenOffice die Möglichkeit den Feldern im Register "Eigenschaften -> Daten" die Option "Leere Zeichenfolge ist NULL" zu geben. Unabhängig davon, was ich da rein schreibe wird in der Datenbank der Spalte ein NULL-Wert zugeordnet. Das funktioniert also nicht. (Bug? Oder verstehe ich da was nicht?)
Gebe ich in der MySQL-Datenbank allen Spalten das Attribut NULL mit dem Standardwert "" (also ohne Eintrag) dann funktioniert es. Allerdings ändert PhpMyadmin jedesmal wenn ich die Spalteneigenschaften editiere diese Attribute wieder so, dass als Standardwert NULL eingetragen ist.
Ich habe ein wenig das Gefühl, ich verstehe das Konzept mit den NULL-Werten nicht richtig.
Kann mir jemand helfen? Wie macht ihr das bei MySQL und OpenOffice?
grüße
laura
Problem mit NULL-Werten in MySQL und OpenOffice
Moderator: Moderatoren
Hey Laura,
viel Verwirrung - und du wirst wohl noch mehr bekommen
Vieles hast du schon richtig erkannt - und beschrieben. Was soll man da noch hinzufügen?
Also: Es gibt DBMS (Data Base Management Systems), die kümmern sich um die Daten und Datenbank selbst. Das ist zum Beispiel MySQL, PostgeSQL aber eben auch HSQLDB.
Dort werden Spalten definiert und die Speicherplätze festgelegt (also z.B. ist NULL).
Dann gibt es "Frontends", die versuchen, die Besonderheiten eines DBMS abzubilden und die Funktionen für den Benutzer möglichst einfach aufzubereiten (Hierzu zählt z.B. MySQL Administrator oder auch phpmyadmin, aber eben auch Base).
Tia, und dann gibt es noch die Transportschicht, also der Treiber, der zwischen DBMS und Frontend die Kommunikation übernimmt (also z.B. der ODBC-Treiber oder der JDBC Treiber)
Tia, und in jedem dieser Schichten können Schwachpunke auftreten, können andere Interpretationen vorgenommen werden und vieles mehr.
So gibt es beispielsweise durchaus Unterschiede, ob du die MySQL Datenbank via ODBC Treiber oder via JDBC Treiber mit Base verknüpfst (meiner Ansicht ist der JDBC Treiber besser, vollständiger) und Base selbst hat die Problematik, dass man mit allen möglichen DBMS zurechtkommen will. Dabei ist der Schwerpunkt aber die HSQLDB - sinnvollerweise, da die Jungs von HSQLDB überwiegend den Baseteil programmiert haben
Das DBMS - ja. Intern sind die Speicherplätze ja irgendwie zu "füllen".
Und im Grunde ist der Umbau der Makro-Formeln doch nicht wirklich aufwendig:
Suchen und ersetzen: %% mit NULL -> läuft über alle Module, Sekundensache.
Auch Base versteht bei weitem nicht alles, was MySQL kann und interpretiert manches "um". Hier hilft eigentlich nur experimentieren und eventuell "drumherum" programmieren. Es gibt einige Kompromisse zu machen zwischen Base und MySQL (auch Versions- und Datenbank-Typ abhängig.)
Aber - nicht den Mut verlieren. Es lassen sich soooo schöne Sachen machen
Viele Grüße
Thomas
viel Verwirrung - und du wirst wohl noch mehr bekommen

Vieles hast du schon richtig erkannt - und beschrieben. Was soll man da noch hinzufügen?
Also: Es gibt DBMS (Data Base Management Systems), die kümmern sich um die Daten und Datenbank selbst. Das ist zum Beispiel MySQL, PostgeSQL aber eben auch HSQLDB.
Dort werden Spalten definiert und die Speicherplätze festgelegt (also z.B. ist NULL).
Dann gibt es "Frontends", die versuchen, die Besonderheiten eines DBMS abzubilden und die Funktionen für den Benutzer möglichst einfach aufzubereiten (Hierzu zählt z.B. MySQL Administrator oder auch phpmyadmin, aber eben auch Base).
Tia, und dann gibt es noch die Transportschicht, also der Treiber, der zwischen DBMS und Frontend die Kommunikation übernimmt (also z.B. der ODBC-Treiber oder der JDBC Treiber)
Tia, und in jedem dieser Schichten können Schwachpunke auftreten, können andere Interpretationen vorgenommen werden und vieles mehr.
So gibt es beispielsweise durchaus Unterschiede, ob du die MySQL Datenbank via ODBC Treiber oder via JDBC Treiber mit Base verknüpfst (meiner Ansicht ist der JDBC Treiber besser, vollständiger) und Base selbst hat die Problematik, dass man mit allen möglichen DBMS zurechtkommen will. Dabei ist der Schwerpunkt aber die HSQLDB - sinnvollerweise, da die Jungs von HSQLDB überwiegend den Baseteil programmiert haben

Sinnvoll. Da Base eine SQL-Befehl (insert) versendet, aber nur die Formularfelder aufführt, reagiert das DBMS so - ist also korrekt. Arbeitest du mit Basic, so kannst due den Insert-String um diese Felder erweitern - oder du fügst sie dem Formular bei - als versteckte Felder und nimmst dirt als Vorgabe "0" oder eben etwas anderes.1. Wenn ich die Tabellenspalten mit dem Attribut NOT NULL versehe meckert OpenOffice, wenn nicht alle TAbellenspalten auch im aktuellen Formular sind und gibt die Fehlermeldung aus: Spalte xyz darf nicht NULL sein.
(Bzw. macht das die Datenbank... da NULL als Standard vorgesehen ist???)
Das DBMS - ja. Intern sind die Speicherplätze ja irgendwie zu "füllen".
Nein. Das ist eigentlich der richtige und typische Weg. Da ist die MySQL Referenz schon OK. Die meisten relationalen DB arbeiten so - die Suche nach "nichts" (%%) ist eher unüblich.Suchfunktion über Makro) Klar, laut MySQL Referenz müsste man IS NULL explizit angeben. Ich könnte nun alle SQL-Abfragen umbauen, damit auch nach NULL-Werten explizit gesucht wird, aber das erscheint mir zu umständlich.
Und im Grunde ist der Umbau der Makro-Formeln doch nicht wirklich aufwendig:
Suchen und ersetzen: %% mit NULL -> läuft über alle Module, Sekundensache.
Nein, unterschiedliche Schichten. Wenn im DBMS NULL vorgesehen ist, wird dies eingetragen - und Base ist eben für viele DBMSD zuständig - funktioniert nur, wenn das DBMS hier nicht eigenständig arbeitet. Kommt außerdem darauf an, ob die Transportschicht (also der Treiber) dies überhaupt "richtig" übermittelt.Bug? Oder verstehe ich da was nicht?
Tia, auch phpmyadmin ist eben "nur" ein Frontend, und die Frage ist, ob dort alle Features richtig interpretiert und unterstützt werden.Allerdings ändert PhpMyadmin jedesmal wenn ich die Spalteneigenschaften editiere diese Attribute wieder so, dass als Standardwert NULL eingetragen ist.
Auch Base versteht bei weitem nicht alles, was MySQL kann und interpretiert manches "um". Hier hilft eigentlich nur experimentieren und eventuell "drumherum" programmieren. Es gibt einige Kompromisse zu machen zwischen Base und MySQL (auch Versions- und Datenbank-Typ abhängig.)
Aber - nicht den Mut verlieren. Es lassen sich soooo schöne Sachen machen

Viele Grüße
Thomas
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic