Forum @ SIB Visions

Ich habe beim unserem jvx Update von 2.0.1 auf 2.5.1 noch einen Unterschied bemerkt.

Es geht darum:
Ich befülle ein MemDataBook "mdbTourData" mit dem Inhalt einer DataRow, die ich einem anderen RemoveDataBook "rdbUser" selektiert habe.
Dieses MemDataBook setze ich als Masterreferenz für ein RemoteDataBook "rdbTourToUser2".
Bei jvx 2.0.1 kommen die entsprechenden Daten aus diesem RemoteDataBook "rdbTourToUser2" zurück, bei jvx 2.5.1 kommen überhaupt keine Daten zurück.

Code: Select all

DataRow dataRow = (DataRow) rdbUser.getDataRow(rdbUser.getSelectedRow());
mdbTourData = new MemDataBook();
mdbTourData.setRowDefinition(dataRow.getRowDefinition());
mdbTourData.setName("_tourData");
mdbTourData.open();
mdbTourData.insert(false);
mdbTourData.setValues(null, dataRow.getValues(null));

rdbTourToUser2 = new RemoteDataBook();
rdbTourToUser2.setDataSource(dataSourceTourManagement);
rdbTourToUser2.setName("tourToUser");
rdbTourToUser2.setMasterReference(new ReferenceDefinition(new String[] {"USER_ID"}, mdbTourData, new String[] {"ID"}));
rdbTourToUser2.open();


Was muss ich hier mit jvx 2.5.1 anders machen?

LG
Martin

Hast du schon mal nachgesehen ob im mdbTourData überhaupt eine Zeile enthalten ist?

Das brauchst du nicht:

Code: Select all

DataRow dataRow = (DataRow) rdbUser.getDataRow(rdbUser.getSelectedRow());

Die aktuell selektierte Zeile ist immer auch eine DataRow, des DataBooks.

Also:

Code: Select all

mdbTourData.setValues(null, rdbUser.getValues(null));

Dann würde ich noch machen:

Code: Select all

mdbTourData = new MemDataBook(rdbUser.getRowDefinition());
...
mdbTourData.saveAllRows();


Und warum brauchst du überhaupt das MemDataBook?

Diese Zeile sorgt dafür, dass die Daten richtig geholt werden:

Code: Select all

mdbTourData.saveAllRows();


Zum Hintergrund:
Meine überflüssige Zeile, mit der ich mir die selektierte DataRow aus rdbUser hole, ist nur da, um meinen Anwendungsfall zu erläutern.
Denn meine Vorgänger haben das MemDataBook dafür verwendet: im Hauptfenster gibt es eine UITable. Wenn man dort eine Zeile doppelklickt, geht ein neues Fenster auf mit Daten, die sich auf die gewählte Zeile beziehen. Dafür übergeben sie im Konstruktor des neuen Fensterobjekts diese selektierte DataRow. Im neuen Fenster erstellen sie eben dann so ein MemDataBook, um sich wie in meinem Beispiel die entsprechenden Daten zu holen.
Mir haben sie die Verwendung des MemDataBooks so erklärt, dass sie nicht wollten, dass die Daten, die man im Fenster ändert, sofort gespeichert werden, sondern erst, wenn man einen "Speichen"-Button klickt.

Frage daher zu dieser Zeile:

Code: Select all

mdbTourData.saveAllRows();


Bewirkt das eh kein tatsächliches Speichern in der DB oder? Es werden nur die Daten im MemDataBook gespeichert - also im Speicher. Stimmt das?

Grundsätzlich:

MemDataBook hält alle Daten im Speicher und es gibt keine Verbindung zur Datenbank. Alle Operationen finden im Memory statt.


Wenn es darum geht die Daten erst durch einen Button zu speichern, muss kein Mehraufwand über ein MemDataBook getrieben werden. Eine Zeile wird erst gespeichern wenn sie verlassen wird, sprich sich die selected Row ändert (gilt für den writeBackIsolationLevel DATAROW). Sie können also ohne weiteres ein Popup mit dem RemoteDataBook öffnen und Speichern bzw. Abbruch Buttons verwenden. Solange die Zeile nicht via API gewechselt wird, wird auch nicht gespeichert.

Wenn ihnen das nicht sicher genugt ist, können Sie auch noch den writeBackIsolationLevel DATASOURCE verwenden. Dadurch wird auch bei Zeilenwechsel noch nicht "gespeichert", sprich die Daten bleiben im Memory und bei save wird dann alles gegen die DB geschickt.

Es gibt natürlich Sonderfälle bei Master/Detail, wodurch der Master gespeichert wird, wenn ein Detail eingefügt wird usw... (zwecks Konsistenz). Dazu müssten wir schon die Maske sehen bzw. wissen wie die genaue Anforderung ist.

Wir hatten in den letzten Jahren schon sehr viele Anwendungsfälle und ein Umweg über ein Kopieren ist uns noch nicht untergekommen. Aber natürlich gibt es immer wieder Überraschungen


Ein saveAllRows bzw. saveSelectedRow ist nötig, damit die Daten "übernommen" werden. Das ist einfach nötig um unnötige fetches zu vermeiden. Wenn bei jedem setValue im Master das Detail geladen werden würde, wär das overhead. Weiters könnte ja ein DB Trigger oder Storage Trigger Spalten aktualisieren, die dann am GUI relevant sind. Daher ist ein save nötig.

Ihr habts vergessen das automatisches commit auch ausgeschaltet werden kann. Bei meiner Applikation hab ich das so gemacht und die ganze Applikation muss manuell committed (gespeichert) oder rollbacked werden