Hallo Florian, > > Ich bin etwas verwirrt, wenn nicht Mal Views übernommen werden sollen.... > Laut dem ESC call könnte es eine 2-3 jährige Übergangszeit geben, also dass > das nächste LTS Release der Linux Distributionen abgewartet wird.
Ich habe diesen Call auch gelesen. Die Übergangszeit würde schon passen. 1. Schritt: Firebird aus dem Experimentalstadium raus. 2. Schritt: HSQLDB nach Firebird migrieren (wenn Firebird stabil genug und begründbar besser funktioniert - nicht wenn Firebird Probleme mit Funktionen hat, die HSQLDB bietet. 3. Schritt: HSQLDB als Deprecated einstufen. Dann sind wir aber auf jeden Fall raus aus der Abwärtskompatibilität. Der Austausch der *.odb-Dateien zwischen neueren LO-Versionen und älteren LO-Versionen und auch AOO ist nicht mehr möglich. 4. Schritt: HSQLDB raus - so wie es jetzt bei der "Migration" versucht wird/wurde. > > Ich finde es eigentlich eine verlorene Chance, dass nicht bei jedem > Dokument, das konvertiert wird zumindest "select * from <name>" verglichen > wird, ob das gleich ist. Denn wenn die Daten passen ist der automatische > Teil der Migration fertig, das SQL anzupassen geht nicht wirklich, oder? Was im Augenblick bei der Migration vermutlich funktioniert ist die Erstellung der Tabellen mit Daten, wenn die Beziehung zwischen den Tabellen nicht definiert wird. Das Gleiche erzeuge ich aber auch, wenn ich einfach Tabellen von der einen Datenbank in die andere ziehe. Da mache ich das dann bewusst. Sobald Beziehungen zwischen den Tabellen definiert werden bekomme ich kein Migrationsergebnis, wenn die Tabellen Inhalt enthalten - so zumindest bei meinen Tests. Wenn Beziehungen definiert sind und die Tabellen leer (kommt bei einer Migration wohl nicht vor), dann werden die Tabellen erstellt, die Tabellen in den Beziehungen aber nicht verknüpft. Ansichten werden grundsätzlich raus gelassen, egal wie kompliziert sie sind. Der SQL-Code von Views ist nicht so sehr unterschiedlich. Das Dumme ist nur, dass der von der Datenbank überprüft wird. Sollte das fehl schlagen, dann könnte als Alternative der SQL-Code des Views als Abfrage in die zu migrierende Datenbank übernommen werden. Sonst ist nämlich der gesamte Code verloren. Ich habe hier views, die eben nicht nur eine Zeile, sondern nahezu eine A4-Seite beinhalten - die weiß ich doch nicht auswendig. Leider funktioniert in der aktuellen 6.1 der Editor für Views nicht einmal. Stattdessen wird bei einem View der Tabelleneditor geöffnet. Views lassen sich nur über Abfragen erzeugen und dann als Ansichten in den Tabellencontainer übernehmen. Ich habe spontan nur die Standarddatenbank des Handbuches an dieser Migration versucht und dann von dieser her abgespeckt. Am Wochenende werde ich etwas mehr testen. Bisher habe ich es nicht geschafft, eine Datenbank mit allen Daten migriert zu bekommen - nicht weil ich Views drin habe, sondern weil ich natürlich Beziehungen definiert habe und meine Tabellen auch bei Testbeispielen natürlich Inhalt enthalten. Die Datei enthält nach der Migration keine Tabellen mehr. Gruß Robert -- Homepage: http://robert.familiegrosskopf.de LibreOffice Community: http://robert.familiegrosskopf.de/map_3 -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
