Leitfaden für die Nutzung von FireDAC-Komponenten

[ioster]

Es muss doch aber irgendwo eine Einstellung geben, die die FireDAC-Connection/-Table dazu veranlasst, die Daten sofort zurückzuschreiben. Ich habe es gerade nochmal ausprobiert: ich erfasse referenzierende Daten in einem Quantumgrid und bin der Meinung alles ausgefüllt zu haben. Selbst wenn ich mit dem Navigator den Datensatz wechsel und wieder zurückblätter wird mir das vorgegaukelt.

In der Datenbank sind aber nicht alle Feldinhalte angekommen und nach dem nächsten Neustart sehe ich auch in der Anwendung das Problem. So kann man doch aber keine vernünftige Anwendung programmieren.

Von Refresh oder Commit ist nirgends in der Dokumentation von Embarcadero die Rede, wenn es um die Bearbeitung von Daten geht. Vielmehr habe ich letzt in einem anderen Zusammenhang den Hinweis auf Live-Daten gefunden, der mir vom Support aber auch nicht näher erläutert wurde. Ich möchte die Daten live haben, live in der Datenbank gespeichert und die aktuellen Daten aus der Datenbank live auf dem Schirm. So kenne ich das aus meiner langjährigen Programmierpraxis, wobei eben FireDAC vollkommen neu für mich ist. Um BDE konnte ich auch immer einen Bogen machen, weil ich mit Komponenten von Extended Systems/Sybase/SAP immer direkten Zugriff auf die Tabellen des Advantage Database Server hatte.

Die Logik der Tabellen sollte eigentlich bei allen Komponenten gleich sein. Deswegen sehe ich das Problem immer noch bei den Einstellungen der FireDAC-Schicht.

Viele Grüße
Ingo

[hoika]

Hallo,

Zitat:

ich erfasse referenzierende Daten in einem Quantumgrid

Aha, gut zu wissen.

Was sagt denn der DB-Monitor beim Wechsel des Records im Grid?
Ich würde jetzt eher mal beim Quantumgrid nachsehen.

[Uwe Raabe]

Um den Fehler in FireDAC zu verorten (oder auch nicht), würde ich eine beliebige simple Tabelle in der DB nehmen, ein TFDTable mit passender Connection auf ein Form setzen und mit einer Table.Open, Table.Edit, <Feld setzen>, Table.Post schauen, ob die Änderung in der DB ankommt. Solche Dinge mache sicher nicht nur ich zuhauf - erfolgreich.

[Delbor]

Hi zusammen

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Gruss
Delbor

[HeZa]

Zitat:

Zitat von Delbor (Beitrag 1451660)

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Hm..., ich programmier eigentlich immer mit FireDAC und SQL

[Delbor]

Hi HeZa

Zitat:

Zitat von HeZa (Beitrag 1451661)

Zitat:

Zitat von Delbor (Beitrag 1451660)

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Hm..., ich programmier eigentlich immer mit FireDAC und SQL

Ach ja, klar, ich auch. Ich hab mich da sehr undeutlich ausgedrückt. So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.
Tabellen gebe ich auch nicht mit den entsprechenden Komponenten aus (DBGrid & Co), sondern per Query-Abfrage und befüllen eines Stringgrids.

Gruss
Delbor

[Frickler]

Zitat:

Zitat von Delbor (Beitrag 1451668)

Ich hab mich da sehr undeutlich ausgedrückt. So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.
Tabellen gebe ich auch nicht mit den entsprechenden Komponenten aus (DBGrid & Co), sondern per Query-Abfrage und befüllen eines Stringgrids.

Für statische Datengitter sicherlich sinnvoll. Aber wenn Du in der Tabelle rumeditieren willst a la Excel, dann kommt ein DBGrid mit "Table"-Komponente Dir sehr entgegen. Drittkomponenten wie InfoPower oder Quantumgrid sind genau darauf ausgelegt mit Bergen an spezialisierten Feldeditoren.

[DasWolf]

Möchte man eine Connection, bei der die Fehlerquellen so gering sind wie möglich, dann sollte man die Finger von den Eigenschaften lassen.
Die Hilfe zu FireDAC ist nicht wirklich praktikabel. Da sind schon zum Teil sehr fragwürdige Beispiele drin.

FDConnection rein ins Formular oder Datenmodul, FDQuery oder FDTable dazu und voilà, es funktioniert.
Sollen Änderungen zwischengespeichert und am Ende der Bearbeitung zur Datenbank geschrieben werden, dann suche mal in der Hilfe nach

Delphi-Quellcode:

CachedUpdates

und

Delphi-Quellcode:

ApplyUpdates

.

[Uwe Raabe]

Zitat:

Zitat von Delbor (Beitrag 1451668)

So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.

Ich habe mittlerweile schon mindestens drei solcher Projekte fast komplett auf die Standardmethoden (Append, Edit, Post, Delete) umschreiben müssen als sie auf Multi-Tier erweitert werden sollten. Bezeichnenderweise waren alle diese Projekte vorher bereits so aufgesetzt worden, dann aber irgendwann SQL-fiziert worden.

[ioster]

Hallo,

vielen Dank für die vielen Rückantworten und Anregungen! Ich komme mit dem Lesen gar nicht mehr nach. Es beruhigt mich aber schon ein wenig, dass ich technisch mit der Nutzung der FDTables und deren Methoden generell richtig liege und meine Einschätzung hinsichtlich der Dokumentation auch nicht falsch ist.

Die DevExpress-Komponenten als Verursacher meiner Phänomene hatte ich nach dem Desaster mit ADS bei der Fehlersuche hinten an gestellt. Wie gesagt, ich versuche mich ja erst einmal in die technischen Feinheiten der FireDAC-Komponenten reinzufuchsen. Der FireDAC-Monitor wirft mir viel zu viele Informationen aus, um damit etwas anfangen zu können. Kann ich das auf ein Minimum reduzieren, also nur die SELECT, UPDATE und DELETE-Befehle anzeigen lassen?

Ein Funktionstest der Anwendung hat mir gerade gezeigt, dass die Daten, die ich als erstes in einer Zelle von einem QuantumGrid eingebe, gespeichert werden. Alle nachfolgenden Eingaben verpuffen. Die Komponenten sind meines Wissens aktuell (Version 19.1.6). Dank Wartungsverträge bekommt man ja ständig Updates. Wenn das ein allgemeines Problem wäre, dann hätten da andere auch schon längst aufgemerkt.

Für mich ist immer noch das größte Problem, dass mir die Zeit wegen diese Datenbankgeschichten in der eigentlichen Programmierung davonläuft. In den letzten 20 Jahren habe ich nie so lange herumbasteln müssen, um eine saubere Datenbehandlung hinzubekommen. Das, was ich hier seit fast sechs Monaten erlebe, wird nur noch vom dem OCX-Gehassel getoppt, das ich mit Visual Basic vor Urzeiten hatte.

Ich werde wohl tatsächlich nochmal mit einem kleinen Testprojekt anfangen müssen, um den Verursacher ausfindig zu machen.

Viele Grüße
Ingo