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
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.
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.
(Bzw. macht das die Datenbank... da NULL als Standard vorgesehen ist???)
Das DBMS - ja. Intern sind die Speicherplätze ja irgendwie zu "füllen".
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.
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.
Und im Grunde ist der Umbau der Makro-Formeln doch nicht wirklich aufwendig:
Suchen und ersetzen: %% mit NULL -> läuft über alle Module, Sekundensache.
Bug? Oder verstehe ich da was nicht?
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.
Allerdings ändert PhpMyadmin jedesmal wenn ich die Spalteneigenschaften editiere diese Attribute wieder so, dass als Standardwert NULL eingetragen ist.
Tia, auch phpmyadmin ist eben "nur" ein Frontend, und die Frage ist, ob dort alle Features richtig interpretiert und unterstützt werden.
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