Hallo Robert, Wenn ich ganz ehrlich sein kann, dann bin ich sehr erschrocken, dass Tabellen und Views (da gibt es nicht wirklich einen deutschen Fachbegriff) nicht transferiert werden. Das Problem hier ist, dass eigentlich gar nichts funktioneirt. Denn Relationen zwischen Tabellen, persistierte Views (Tabellen) und virtuelle Views ( eben die Views / Ansichten) sind genauso wie die folgenden Sachen grundfunktionen und müssen transferiert werden:
INDEX, Primärschlüssel (über ein Feld und über mehrere Felder), UNIQUE (und andere) Konstraints wie "NICHT NULL". Ich glaube, dass es sinnvoll wäre ein Dokument mit allen Features zu erstellen und zu beschreiben, was da sein soll (Tabelle mit Primärschlüssel X, Y ist der Sekundärschlüssel für die Relation zur Tabelle Z). Damit hätten wir einen sehr wichtigen Aspekt angegangen. Danach müssen wir sicherstellen, dass alle automatisch generierten SQL Queries funktionieren. Da kann es zu gröberen Problemen kommen, wenn der SQL Standard nicht gleich implementiert ist. Ich würde sagen, dass eine Umstellung erst dann passieren soll, wenn dies und zusäztlich natürlich echte Base Dokumente getestet wurden und sie funktionieren. Aber ich glaub momentan wäre es gut ein Dokument zu haben, wo man sieht was alles nicht geht.... (Mit sehr wenigen bis gar keinen Daten drinnen.) 3) Ich muss sagen ich komme aus der Java Welt und da wurde - trotz deprication - noch nichts nennenswertes entfernt. Darum wäre ich eigentlich dafür HSQLDB mit 6.1 als Deprecated zu markieren und mindestens 3 Releases als Übergangsperiode zu definieren. 3 Releases später wird Firebird default. @Robert: Sind die Fehler hier aufgrund der Konvertierung. Firebird selbst - also wenn man eine ODB mit dem erstellt. Kann man das gut verwenden oder sind wir auch da nich nicht weit genug..? Danke für deine Antworten. Bin schon sehr auf deine Test Ergebnijsse gespannt. lg Florian Robert Großkopf <rob...@familiegrosskopf.de> schrieb am Fr., 13. Apr. 2018, 08:05: > 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 > -- Mit freundlichen Grüßen, | Yours, Florian Reisinger -- 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
