LibreOffice Base NULLPOINTEREXCEPTION

Hallo Zusammen,

ich will meine Bilddatenbank nach über 20 Jahren mit Lotus Approach in LO Base überführen.
Die Index und Bildspalten habe ich vor dem geplanten Import nach Base rausgenommen. Egal wie ich die Daten eibfügen will (ob csv, dbf oder ods) ich bekomme immer wieder die beigefügte Fehlermeldung:

grafik

Meine LO Version ist:
LO Version: 7.1.4.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 12; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: CL

Das noch vorhandene Feld Index soll nicht als Primärindex ID verwendet werden.

Vielen Dank im voraus für die Unterstützung
Roland

Ohne die Tabellen-Definition lässt sich wenig dazu sagen, aber die Fehlermeldung ist erstmal eindeutig: Du willst in einer Zeile ein Feld leer lassen, bei der die Tabellendefinition sagt, dass eine Eingabe nötig ist.

Auffällig ist, dass Du schreibst, dass Du den Index weglässt, aber ein Index-Feld auftaucht. Dessen Definition würde ich mir als erstes ansehen.

Ansonsten erstmal die Frage “weitermachen” mit yes beantworten und schauen, ob etwas importiert wird. Wenn dem so ist herausfinden welche Datensätze fehlen, und worin die sich von den anderen unterscheiden.

Wenn nichts ankommt wurde ich bei der ID anfangen, wenn Deine Tabelle eine hat. Funktioniert das Autoinkrement? Wenn ich über die GUI kopiere übergebe ich oft ein leeres ID-Feld und Base ergänzt eine ID-Nummer…

Hallo Wanderer,

alle Felder außer Datum sind als Text formatiert, da nicht berechnet werden soll. Die Feldnamen stehen in der Fehlermeldung. Das Feld ID soll beim Import erzeugt werden. Kein Feld hat die Vorgabe das eine Eingabe nötig ist. Das Feld Index hat das Format xxxx.xx.xx.xxxx und dient mirdazu um Bilder aus verschiedenen Quellen in eine zeitliche Reihenfolge zu bringen. Insgesamt hat die Datenbank aktuelle 120.000 Sätze.

Gruß
Roland

Was Du unter “LO Base Datenbank” verstehst ist in Wirklichkeit eine HyperSQL-Datenbank, die in einem Containerdokument eingebettet ist. Das Datenbankdokument ist ein zip-Archiv. Diese Art von Datenbank ist mit einigen Nachteilen und Einschränkungen behaftet und man sollte nie große Mengen an Bildern in Blob-Feldern speichern. Wenn Du schon eine eingebettete Datenbank verwendest, dann speicher die Bilder in einem Verzeichnis und speicher die relativen Pfade in einem Textfeld. Die Bilder sind dann genauso in Formularen und Berichten verwendbar wie eingebettette Bilder. Das Problem ist nicht HyperSQL. Das Hauptproblem ist die Art wie die Datenbank eingebettet ist. Bei großen Datenmengen droht totaler Datenverlust wenn z.B. der PC herunterfährt oder in den Sparmodus geht während die Datenbank zurück ins zip-Archiv kopiert wird.

Einfach mal mit 5-10 Datensätzen probieren, ob das klappt.
Ich würde sonst entweder das ID-Feld schon in Calc erzeugen z.B. indem =ZEILE(A1) in der ersten Spalte herunterkopiert wird, oder eben vorher in der Tabellendefinition in Base das ID-Feld mit Autoincrement anlegen, dann wird es beim kopieren von Calc aus gefüllt, wenn es leer ist.

Nur als Nebenbemerkung: Für den Zweck extrahiere ich via ExiifTool die Eigenschaft DateTimeOriginal aus der .jpg-Datei

Scheint der klassische Fehler zu sein. Da ist in der Tabelle nach der Fehlermeldung ein Feld “ID”. Das Feld taucht nicht in dem INSERT-Befehl auf, soll also vermutlich der Primärschlüssel sein. Und der wird nicht automatisch erstellt, solange kein AutoWert in der Tabelle bei der Erstellung vorgewählt wurde.

Und wenn man die Tabelle via Kopieren&Einfügen erstellt (oder mit dem idiotischen “Assistenten”), dann ist der automatisch erzeugte Primärschlüssel nie automatisch hochzählend (was in 90% der Fälle Quatsch ist).
@ llav,
Es mag vielleicht etwas mühsamer sein, aber es lohnt sich in aller Regel, die Tabellen, Relationen und Indizes (also das Datenbank-Backend) zuerst zu erstellen und dann die Daten aus einer anderen Datenbankverbindung oder aus Calc in die fertige Struktur hineinzukopieren (“Daten anhängen”). Beim Einfügen einfach “Struktur und Daten” auszuwählen erzeugt eigentlich nie etwas brauchbares.

Guten Abend Zusammen,

vielen Dank für die Antworten. Die Tabelle ist eingefügt. Am Anfang erst mal 10 Stück, danach immer mehr. 120.000 Datensätze auf einmal waren wohl zuviel. Den Hinweis mit den verknüpften Bilder nutze ich. Nachdem ich einen ganzen Nachmittag verbracht habe funktioniert die Anzeige der Bilder im Formular und im Bericht. Wobei über den Bericht breiten wir besser den Mantel des Schweigens. Ich bastle Mal weiter rum und werde mir Erlauben bei Gelegenheit noch mal zu Fragen.

Seid mir nicht Böse aber ich weine Approach nach :frowning:

Danke für die Unterstützung
Roland

Lotus Approach unterstützte viele Datenbanktypen, standardmäßig hat es wohl dBase erzeugt. Du kannst eventuell ein Datenbankdokument mit der Approach-DB verbinden, die notwendigen Abfragen, Formulare und Berichte erstellen, um einfach mit derselben Datenbank weiterarbeiten. Oder Deine Daten von dieser Datenbank in die sogenannte “Base Datenbank” kopieren. Ich kopiere Datenbankdaten meistens von Calc nach Base.

Base ist zunächst einmal nur ein Frontend. Du kannst das Frontend via JDBC oder ODBC mit allen relationalen Datenbanken verbinden, für die Du einen Treiber hast. Für manche Datenbanken gibt es angepasste LibreOffice-Treiber (MySQL z.B.).
Wenn Du mit Base eine neue Datenbank erstellst, dann wird eine HyperSQL-Datenbank erzeugt und in das Base-Dokument eingebettet. Du erkennst die Art der Verbindung an dem Schriftzug in der Statuszeile. Da steht wahrscheinlich bei Dir “HSQL embedded”. Das ist die zweitmieseste Lösung überhaupt, geeignet für Demos und Unterrichtszwecke oder die private DVD-Sammlung. Nicht weil HyperSQL schlecht wäre, sondern weil die Art der Einbettung früher oder später zu totalem Datenverlust führt. Soviel zum Thema “Base Datenbank”. Sollte jeder wissen und ich schreibe mit deshalb seit 15 Jahren die Finger wund.
Base ist kein Entwickler-Tool für Datenbanken oder wenn, dann nur ein ziemlich schlechtes. Es ist in allererster Linie eine Brücke zwischen Datenbanken und Officedokumenten. Du hast bereits existierende Datenbanken und kannst diese innerhalb weniger Minuten mit Deinen Officedokumenten verbinden, sinnvolle Abfragen erstellen und damit dann hübsch formatierte Berichte in Form von Officedokumenten erstellen. Das einzige, was so ein klein wenig in Richtung “Entwicklung” geht sind die Formulare. Die stellen nämlich Benutzerschnittstellen zum Bearbeiten von relational verknüften Tabellen dar. Von vornherein vergessen kannst Du aber den “Formularassistenten” weil der nicht einmal 10% aller Möglichkeiten ankratzt. Eigentlich kann der so gut wie nichts und lässt den Entwickler dann im Regen stehen. Von Makros will ich hier gar nicht anfangen. Die API bringt selbst erfahrene Entwickler zum Weinen.
Vielleicht überlegst Du Dir das alles nochmal und setzt erstmal auf ein etabliertes Backend wie PostgreSQL oder MySQL.
Du kannst natürlich auch mit “embedded HSQL” erstmal weitermachen und die Datenbank später in eine externe HSQL-Datenbank umwandeln. Die ist dann durchaus vergleichbar mit anderen relationalen Datenbanken und auch zuverlässig. Solange Du mit “embedded HSQL” arbeitest, solltest Du immer darauf achten, dass alles gespeichert und kein Datensatz geöffnet ist wenn Dein Rechner in den Ruhemodus geht oder herunterfährt oder abstürzt. Tägliche Backups sind ein Muss.