Moin Micha,

Wenn ich mir mit der aktuellen Version ein neues Projekt anlege und in dieses ein älteres, migrieren möchte erhalte sich einen I/O-Fehler (siehe E-Mail). Dies tritt interessanterweise dann auf, wenn das Alt-Projekt bereits durch eine Migration entstanden ist. Zumindest konnte ich das mit diesem Ansatz reproduzieren.

Kannst Du das verifizieren?

Viele Grüße
Pierre

Hallo Pierre,

Wenn ich mir mit der aktuellen Version ein neues Projekt anlege und in dieses ein älteres, migrieren möchte erhalte sich einen I/O-Fehler (siehe E-Mail).

Danke für den Hinweis. Laut Deiner Mail ist die Fehlermeldung:

java.sql.SQLException: java.sql.SQLSyntaxErrorException: unexpected token: WHERE in
 statement [SELECT "start_point_name", "end_point_name", "enable" WHERE "group_id" = ? 
ORDER BY "id" ASC]
 at org.applied_geodesy.jag3d.ui.io.sql.OADBReader.readAndImport(OADBReader.java:125)

Es wird also ein SQL Statement nicht korrekt ausgeführt. Konkret das für die Deformationsvektoren. Hier scheint der Tabellenname CongruenceAnalysisPointPairApriori zu fehlen. Der vollständige Ausdruck sollte lauten:

SELECT 
"start_point_name", "end_point_name", "enable" 
FROM "CongruenceAnalysisPointPairApriori" 
WHERE "group_id" = ? ORDER BY "id" ASC

Der Fehler tritt also nur auf, wenn Deformationsvektoren vorhanden waren im früheren Projekt.

Kannst Du das verifizieren?

Ich denke. Kannst Du mal bitte die jag3d.jar bei Dir austauschen mit folgender jag3d.zip und probieren, ob es dann geht? Wenn ja, würde ich direkt heute eine neue Version herausbringen.

Bitte beachte, dass alte Projekte nur migriert werden können, wenn deren Datenbank zuvor aktualisiert wurde. In Deinem Fall ist dies aber so, da Du sonst eine andere Fehlermeldung erhalten würdest, siehe Screenshot (Hervorhebung). Bei Dir ist diese Prüfung bereits erfolgreich (und positiv) gewesen. Beachte auch, dass Deformationsvektoren in dem zu migrierenden Projekt vorhanden sein müssen, da sonst das Problem nicht auftreten kann.

Über eine kurze Rückmeldung freue ich mich.

Viele Grüße
Micha

Moin Micha,

mit der ausgetauschten jar-File ist das Problem beseitigt - die Migration läuft problemlos durch.

Mir ist noch eine andere Sache aufgefallen und zwar, dass die Spalte für $\sigma_0$ in den Beobachtungs-Rohdaten nun ganz zu Beginn im Dateneditor (Testprojekt siehe E-Mail) steht also noch vor Start- und Zielpunkt. Du hattest ja Features zur Spaltensortierung und Spaltenbreite implementiert ... kommt es hierdurch bei Alt-Projekten vielleicht zu solchen Effekten?

Grundsätzlich, welche Daten, Einstellung werden bei der Migration importiert - alles was im Datenbaum steckt?

Viele Grüße
Pierre

Hallo Pierre,

mit der ausgetauschten jar-File ist das Problem beseitigt - die Migration läuft problemlos durch.

Danke fürs Feedback. Ich werde eine neue Version bereitstellen.

Grundsätzlich, welche Daten, Einstellung werden bei der Migration importiert - alles was im Datenbaum steckt?

Es werden die Rohdaten und die Gruppeneinstellungen (bspw. stochastisches Modell) migriert, sofern es keinen Konflikt gibt (bspw. identische Punktnummern). Die Ergebnisse selbst werden nicht portiert, da diese nach der Portierung sicher nicht mehr stimmen und eine Neuausgleichung mit den vorhandenen Daten notwendig wird.

Mir ist noch eine andere Sache aufgefallen und zwar, dass die Spalte für $\sigma_0$ in den Beobachtungs-Rohdaten nun ganz zu Beginn im Dateneditor (Testprojekt siehe E-Mail) steht also noch vor Start- und Zielpunkt. Du hattest ja Features zur Spaltensortierung und Spaltenbreite implementiert ... kommt es hierdurch bei Alt-Projekten vielleicht zu solchen Effekten?

Hmm, ja, dass könnte sein - sollte aber ganz klar nicht sein. Passiert das immer bei Dir? Passiert es auch bei neuen Projekten oder nur bei alten, die Du mit einer neuen Version öffnest?

Wenn ich Dein Projekt öffne, sehe ich zwar den Effekt aber kann die Ursache nicht mehr rekonstruieren. Wenn Du also ein altes Projekt geöffnet hast, dann gab es die SQL-Tabelle noch nicht, welche die Spalteneigenschaften speichert. Diese wird dann erst angelegt, siehe nachfolgenden Screenshot.

Die markierte Zeile ist Deine Problemstelle. Der Tabellentyp (hier: 1) ist das Nivellement und der Spaltentyp (hier: 51) und, wie Du in der letzten Spalte siehst, diese Tabellenspalte hat den Index 0 erhalten. Wenn ich Dein Projekt also öffne, wird diese Tabelle (jetzt) ausgelesen und die Tabelle entsprechend sortiert. Die $\sigma_0$-Spalte sollte nun also immer ganz vorne stehen, sofern Du die Spalte nicht verschiebst.

Das Problem ist jetzt, warum wurde beim ersten Aufruf (also als diese Tabelle erzeugt wurde), die Spalte mit dem Index Null versehen. Hast Du alte Projekt noch (in einem Archiv), die Du noch nicht mit der aktuellen Version geöffnet hast?

Viele Grüße
Micha

Hallo Pierre,

Mir ist noch eine andere Sache aufgefallen und zwar, dass die Spalte für $\sigma_0$ in den Beobachtungs-Rohdaten nun ganz zu Beginn im Dateneditor (Testprojekt siehe E-Mail) steht also noch vor Start- und Zielpunkt. Du hattest ja Features zur Spaltensortierung und Spaltenbreite implementiert ... kommt es hierdurch bei Alt-Projekten vielleicht zu solchen Effekten?

Ich habe jetzt einige Fälle durchgespielt und kann das Verhalten bestätigen. Es tritt sogar auf, wenn man ein Projekt öffnet und sofort wieder schließt und wieder öffnet. Probleme hatte ich auch, wenn ich zwischen verschiedenen Projekten wechselte (ohne JAG3D zu schließen).
Ich habe zwei Stellen modifiziert, wovon eine sehr vielversprechend erscheint. Ich habe Dir wieder eine Testversion erstellt. Kannst Du Deine jag3d.jar wieder durch die in jag3d.zip ersetzen und mal rumprobieren?

Beachte bitte, dass das Verhalten scheinbar noch bestehen bleibt, wenn in der DB bereits falsche Spaltenpositionen stehen. Da ich nicht prüfen kann, ob es eine gewollte Sortierung ist vom Anwender oder eben eine von mir verursachte, sehe ich keine Chance es zu korrigieren. Du müsstest also die $\sigma_0$-Spalte händisch korrigieren - dann sollte die da aber bleiben. Alternativ könntest Du die Tabelle vorher leeren. Hierzu müsstest Du die DB öffnen (siehe Screenshot 1), die Tabelle leeren (siehe Screenshot 2), und am Ende den Befehl SHUTDOWN noch ausführen um die DB zu schließen. (Ich habe für die Screenshots die hsqldb.jar aus dem Lib-Verzeichnis in Dein Projektverzeichnis kopiert, sodass kein Pfad angegeben ist beim Login.) In der finalen Version würde ich die Tabelle so resetten und neu aufbauen.

Viele Grüße
Micha

Nabend Micha,

hat leider ein wenig gedauert, sorry. Ich habe die jar-Datei ausgetauscht und ein wenig rumprobiert. Bei den Projekten wo es zu der Verschiebung der Spalte kam, steht diese natürlich immernoch an der falschen Position - wie Du auch schon vermutet hast. Korrigiere ich dies manuell und öffne die Projekte erneut, so ist die Position nun korrekt und bleibt auch so. Bei Projekten, welche noch nicht mit dem aktuellsten Release geöffnet wurden, tritt nach dem Austausch der jar-Datei keine Verschiebung der Spalte mehr auf.

Ich glaube, dass Du die richtigen Stellen erfolgreich modifiziert hast.

Vielen Dank und Viele Grüße
Pierre

Hallo Pierre,

besten Dank fürs Melden der Unstimmigkeiten und fürs Ausprobieren der Vorversionen! Ich habe gerade ein das neue Release JAG3Dv20210315 erstellt und hochgeladen, welches die von Dir gefundenen Fehler nicht mehr hat. Bitte nicht wundern, ich lasse JAG3D bei github nun unter dem generischen Account applied-geodesy laufen, sodass ich fachliches von ggf. privaten trennen kann. Solltest Du Links zu github gespeichert haben, so sollten diese automatisch auf die neue Adresse zeigen. Du müsstest also nichts tun.

Ich glaube, dass Du die richtigen Stellen erfolgreich modifiziert hast.

Danke

Viele Grüße und nochmals herzlichen Dank!
Micha

Hallo,

zur Info: Ich habe gestern Abend noch eine leicht veränderte Version online gestellt, da die Tabellen mit den Varianzkomponenten bei den Beobachtungen noch fehlerhaft waren.

Viele Grüße
Micha