Firedac SchemaAdapter Problem!

[Mavarik]

Hallo Zusammen!

Zitat:

Zitat von Offtopic

Firedac ist jenseits von intuitiv bedienbar!

Ich habe eine Tabelle "Test" auf einem lokalen MySQL Server.
FDConnection<-FDQuery<-FDSchemaAdapter
Naja und FDGUIxWaitCursor & FDStanStorageBinLink
mit

Delphi-Quellcode:

fdQuery.SQL := 'SELECT * FROM {id Test}';
fdQuery.Active := true;

Hole ich mir alle Daten in ein Grid
DBGrid<- DataSource <- FDQuery
Soweit so gut.

Mit einen Butten schreibe ich den SchemaAdapter auf die Platte.

Delphi-Quellcode:

FDSchemaAdapter.SaveToFile('DIV.DAT',sfBinary);
FDSchemaAdapter.ApplyUpdates;

Ups... ALLE Datensätze werden auf die Platte geschrieben.
Jetzt ändere ich einen Datensatz (fdquery.CachedUpdates := true) und drücke den Button nochmal.
Und schon wieder werden alle Daten auf die Platte geschrieben!
Wie schaffe ich es das nur die Änderungen vom fdSchemaAdapter gespeichert werden?

Grüsse Mavarik

[Daniel]

Laut Doku sollte es die Eigenschaft ".Delta" sein, die Dir die Menge der geänderten Datensätze gibt.
http://docwiki.embarcadero.com/RADSt...ates_(FireDAC)

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279647)

Laut Doku sollte es die Eigenschaft ".Delta" sein, die Dir die Menge der geänderten Datensätze gibt.
http://docwiki.embarcadero.com/RADSt...ates_(FireDAC)

Ja aber das ist die Property des FDQuery und nicht des SchemaAdapters...

Ich habe doch extra einen SchemaAdapter, der die Änderungen zentralisieren soll, oder?

[Daniel]

Ja, aber der zentralisiert die Änderungen aller an ihn angebundenen DataSets.
Du kannst ihn nach den Datasets fragen und dann das jeweilige Delta abrufen. Jeder dieser DataSets kann ja ein völlig anderes Feld-Layout haben, das alles in einem gemeinsamen Topf verwalten zu wollen, ergibt keinen Sinn.

Was möchtest Du denn erreichen?

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279651)

Was möchtest Du denn erreichen?

Ich möchte die Änderungen von N-Querys in einem SchemaAdapter serialisieren und die Daten von da aus per Bin-Stream oder ggf. JSon zu einem anderen (entfernten) SchemaAdapter transportieren um auf der anderen Seite einen Load und den ApplyUpdates zu machen.

Für alle Fälle wo PC1 nicht per Datenbankverbindung zu Datenserver verbinden kann.

Mavarik

PS.: Könnte ggf. auch per eMail sein. :stupid:

[Daniel]

Zur Not kannst Du ihm ja mal die Option "siData" aus dessen Eigenschaft "ResourceOptions.StoreItems" wegnehmen.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279654)

Zur Not kannst Du ihm ja mal die Option "siData" aus dessen Eigenschaft "ResourceOptions.StoreItems" wegnehmen.

OK Das war schon mal der 1. Schritt, Danke..

Jetzt müsste ich nur noch den Change-Puffer löschen, denn obwohl ich ApplyUpdates gemacht habe,
kommen beim 2., 3. usw. immer noch die Änderungen vom 1. mal mit...

Mavarik

[Daniel]

Zitat:

After applying updates, the changed records still remain in the changes log. To remove them from the changes log and mark them as unmodified, call the CommitUpdates method of each DataSet.

Also in etwa wie folgt:

Delphi-Quellcode:

FDConnection1.StartTransaction;
iErrors := FDSchemaAdapter1.ApplyUpdates;
if iErrors = 0 then
 begin
  for x := 0 to FDSchemeAdapter1.Count-1 do
    FDSchemaAdapter1.DataSets[x].CommitUpdates;
  FDConnection1.Commit;
end
else
  FDConnection1.Rollback;

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279658)

Zitat:

After applying updates, the changed records still remain in the changes log. To remove them from the changes log and mark them as unmodified, call the CommitUpdates method of each DataSet.

Ja schon klar... Das setzt ja aber wieder eine Verbindung zum Datenbank Server voraus...

Ich suche ja nach eine "Aktenkoffer-Lösung"...

Nach dem Motto: "arbeite mal schön weiter, auch ohne Internetverbindung auf Deinen MemTablen"...

Der SchemaAdapter merk sich alle Änderungen. Bevor ich die App beende, wird der Change-Log auf die Platte geschrieben.


Mavarik

[Daniel]

Aus Sicht der DB-Komponenten ist das Verhalten genau richtig. Die können ja nicht wissen, dass Du die Daten schon anderweitig losgeworden bist.

Es geht also um die Frage, wie Du einem TDataSet mitteilen kannst, dass er die Information, dass da Datensätze aktualisiert wurden, vergessen und seinen Zustand als "aktuell" betrachten kann.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279666)

Aus Sicht der DB-Komponenten ist das Verhalten genau richtig. Die können ja nicht wissen, dass Du die Daten schon anderweitig losgeworden bist.

Es geht also um die Frage, wie Du einem TDataSet mitteilen kannst, dass er die Information, dass da Datensätze aktualisiert wurden, vergessen und seinen Zustand als "aktuell" betrachten kann.

Im Prinzip ja streiche TDataSet setzt SchemaAdapter und ich bin zufrieden...:roll:

[Daniel]

Der SchemaAdapter selbst merkt sich das nicht, er verwaltet nur eine Liste an TDataSets - so geht es aus dessen Quellcode hervor.
Im Prinzip greifst Du doch - zumindest aus Daten-Sicht - in das Transaktions-Handling ein, indem Du die Daten anderweitig weiterleitest und den dann neuen Zustand als "Commited" betrachtest.

Eventuell solltest Du Deine Daten tatsächlich in eine MemTable kopieren - das geht bei FireDAC ja einfach. Auf der MemTable wird dann gearbeitet und wenn eine echte DB-Verbindung besteht, dann werden die Daten in die originale Query zurück kopiert und wenn keine Verbindung besteht, gehst Du den Weg über den SchemaAdapter - nur eben mit der MemTable als Quelle.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1279670)

Der SchemaAdapter selbst merkt sich das nicht, er verwaltet nur eine Liste an TDataSets - so geht es aus dessen Quellcode hervor.
Im Prinzip greifst Du doch - zumindest aus Daten-Sicht - in das Transaktions-Handling ein, indem Du die Daten anderweitig weiterleitest und den dann neuen Zustand als "Commited" betrachtest.

Eventuell solltest Du Deine Daten tatsächlich in eine MemTable kopieren - das geht bei FireDAC ja einfach. Auf der MemTable wird dann gearbeitet und wenn eine echte DB-Verbindung besteht, dann werden die Daten in die originale Query zurück kopiert und wenn keine Verbindung besteht, gehst Du den Weg über den SchemaAdapter - nur eben mit der MemTable als Quelle.

Ja hab ich auch gesehen... Wenn Query.Active := False ist dann kann der SchemaAdapter auch nix mehr weg schreiben.

Problem ist, dass die MemTable+Command+TableAdapter=Query Memtable hat keinen Eintrag für SchemaAdapter... nur wieder über den Adapter und der brauch ein Command und der braucht eine Connection...

wie gesagt...

Zitat:

Zitat von Offtopic

Firedac ist jenseits von intuitiv bedienbar!

Vielleicht dann doch besser aus dem Query.Delta die Sache per Hand machen...

Mavarik

[Mavarik]

Also!

Delphi-Quellcode:

  FDMemTable1.Active := False;
  FDMemTable1.Data := FDQuery1.Delta;
  FDMemTable1.SaveToFile('Div.xml',sfXML); // nur mal so XML sieht besser aus...

Das bringt fast schon den gewünschten Erfolg!

Leider ist im "log" jedes mal der komplette Datensatz vor und nach der Änderung und nicht nur der Div...
Das ist natürlich viel zu viel...

Mal sehen was man da machen kann... Schön wäre eine Sequenz von UPDATE befehlen...

[Uwe Raabe]

Hast du schon mal CommitUpdates ausprobiert?

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1279680)

Hast du schon mal CommitUpdates ausprobiert?

Ich will es ja gar nicht Committen...

Ich brauche eigentlich nur eine AUDIT-Liste...

Code:

Tabelle;ID;Feldname;NeuerWert;
Testdb;22012;Name;"Cooler Jo"

Zur "not" noch

Code:

Tabelle;ID;Feldname;AlterWert;NeuerWert;TimeStamp;User;
TestDB;22012;Name;"Coolr Jo";"Cooler Jo";2014-11-11 20:10.12;"Mavarik"
TestDB;22012;ID=DELETE;;;2014-11-11 20:12.12;"Mavarik"

Das Ganze in eine Que geschrieben und ein Thread, der wenn eine Internet_Verbindung besteht diese abarbeiten und zum Server überträgt.

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1279681)

Zitat:

Zitat von Uwe Raabe (Beitrag 1279680)

Hast du schon mal CommitUpdates ausprobiert?

Ich will es ja gar nicht Committen...

Tut es ja auch nicht. Das sorgt nur dafür, daß die Änderungen aus dem Änderungsprotokoll als in Stein gemeißelt gelten und das Delta hinterher wieder leer ist. Entspricht ungefähr dem

Delphi-Quellcode:

MergeChangeLog

des

Delphi-Quellcode:

TClientDataSet

.

[Mavarik]

Ich hole den Beitrag nochmal hoch...

Gibt es eine Möglichkeit die Updates auf eine Datenbank in ein Journal zu schreiben?

Damit eine 2. Datenbank (Lokal) die Änderungen nachträglich in gleicher Reihenfolge nachholen kann?

Hat jemand ein Working Demo?

Mavarik