Re: [de-discuss] Automatische Migration von integrierten HSQLDB ODB-Dateien nach integrierten Firebird-Datenbank ODB-Dateien

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+unsubscribe@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