Inhalt einer Datenbanktabelle in GUI aktuell halten

[Computerbabalulu]

Hallo Ihr lieben

Ich habe eine Gui Anwendung Win32 mit Delphi XE2 erstellt,
welche unter anderem in eine TreeView Daten aus eine MySql Tabelle anzeigt.

Das Treeview befülle ich aktuell mit einem ganz normalen Select (MyDac Komponenten).
Um die Daten relativ aktuell zu halten, wiederhole ich das ganze alle 10 sec....
Also, SQL Abfrage erneut ausführen, TreeView leeren und neu befüllen.

Jetzt zu meiner Frage... Macht das überhaut Sinn so, oder gibt es bessere Lösungen?

Ich bin da in SQL nicht so fit...

Gruß
Baba

[Iwo Asnet]

Schreib in der DB einfach irgendwo hin (z.B. über einen Trigger, kann das MySQL überhaupt?), wenn sich Daten verändert haben.

Anstatt präventiv alle Daten neu zu laden, schaust Du zunerst nur auf diesen Eintrag. Nur wenn dort drin steht "Hat sich geändert", lädst Du entweder alle Daten neu oder nur die, die sich geändert haben.

Oder du verschickst TCP-Nachrichten, wenn sich was ändert.

[Computerbabalulu]

Ja, Trigger kann MySQL. Aber ob ich über einen Trigger aus MySQL heraus via TCP/IP eine Nachricht an die Gui Application
schicken kann, glaube ich nicht. Aber ich Google mal nach. Einen Outfile kann man mit einem Trigger jedenfalls erstellen,
aber dann müsste ich auch wieder ständig nach diesem File triggern...

[RWarnecke]

Was Iwo wohl eher meinte, Du machst Dir eine temporäre Tabelle. In eine Spalte schreibst Du rein, dass sich in Tabelle xy etwas geändert hat oder nicht. Steht jetzt drin : Geändert Tabelle XY, dann lädst Du die entsprechende Tabelle neu.

[Computerbabalulu]

Hallo ihr beiden

Danke für die Infos!
Ich denke so werde ich es machen...

Schönen Abend
liebe Grüße
Baba

[neo4a]

Zitat:

Zitat von Computerbabalulu (Beitrag 1145069)

Jetzt zu meiner Frage... Macht das überhaut Sinn so, oder gibt es bessere Lösungen? Ich bin da in SQL nicht so fit...

Vielleicht ist das nicht nur ein SQL-Problem. Im SVN vom VirtualTreeView gibt es unter Demos\Objects ein MVC-Sample von Marian Aldenhövel, der einen anderen, wenn auch nicht ganz trivialen Ansatz zeigt. Den kann man nun so modifizieren, dass man direkt mit DB-Abfragen und -Werten arbeitet, ohne die Ergebnisse komplett irgendwo in einer Struktur zwischen zu speichern. Die Kernfunktionalität findet hier statt.

Delphi-Quellcode:

  protected
    procedure DoInitChildren(Node:PVirtualNode;var ChildCount:Cardinal); override;
    procedure DoInitNode(aParent,aNode:PVirtualNode; var aInitStates:TVirtualNodeInitStates); override;

Damit ruft der VTV nur noch die Daten ab, die aktuell angezeigt werden, was den TreeView- Aufbau extrem beschleunigen kann. Die anderen Hinweise zum Triggern von Änderungen in der DB gelten natürlich trotzdem.

BTW, ändere diese Funktion in der Demo, damit es in D2009ff keine AV's gibt bzw. auch etwas angezeigt wird:

Delphi-Quellcode:

function TMVCTreeView.InternalData(Node: PVirtualNode): Pointer;
begin
  if (Node = RootNode) or (Node = nil) then
    Result := nil
  else
    Result := PAnsiChar(Node) + FInternalDataOffset;
end;

[tsteinmaurer]

Müßte ich in Firebird eine zeitnahe Aktualisierung der Anzeige bei einer Datenänderung ohne Polling machen müssen, dann würden sich die in PSQL und somit in Triggern vorhandenen asynchronen Events anbieten. D.h. bei einer Datenänderung feuert der Trigger der wiederum den Event auslöst der von "interessierten" Clients empfangen wird und dann im Client eine entsprechende Programmlogik ausführt. Keine Ahnung ob MySQL etwas in Richtung asynchrone Events anbietet.

[mjustin]

Neben Polling gibt es noch die Möglichkeit, die Nachrichten von der Quelle (d.h. von der Anwendung, die Daten ändert) an das Ziel (die Anwendung mit GUI) zu senden.

Mit UDP Broadcast wäre es zwar nicht hundertprozentig zuverlässig aber mit wenig Aufwand machbar. Nur bei großer Anzahl Empfänger würden auch die Pakete das Netzwerk unnötig belasten (da ja immer an alle gesendet wird).

Über einen zentralen Messaging Server ginge es eleganter - Clients, die gerade das betreffende Treeview anzeigen, senden dem Server eine Nachricht "Hallo, ich bin Client X, und würde ab jetzt gerne eine Nachricht über Änderungen in Tabelle Y erhalten". Über TCP kann der Client dann asynchrone Nachrichten empfangen. Bei Indy sind dazu im Prinzip schon alle Komponenten enthalten.

Auf dem Weg über den Datenbankserver geht es zwar auch, bei InterBase (Version 5) schossen die Events damals aber immer die Clients ab, so dass wir es schnell sein liessen. Ein größeres Risiko ist, dass der Code für die Events im Prozess des Datenbankservers selber läuft. Wenn darin ein Fehler auftritt, kann das die Stabilität gefährden bis hin zum Absturz.

[tsteinmaurer]

Hallo Michael,

richtig, Events in InterBase und Firebird verursachten immer wieder mal Probleme, z.B. in blockierende Clients, wenn eine Firewall dazwischenfunkte etc. Kann jetzt nur von Firebird sprechen und da hat sich in jedem Release bzgl. Stabilität etwas getan, d.h. diese Dinger wurden besser und stabiler. Vor allem mit Firebird 2.5 lässt sich nun auch der RemoteAuxPort Parameter in firebird.conf für Classic und SuperClassic verwenden, um einen TCP Port für die Eventkommunikation zu definieren. In < 2.5 ging das in Classic nur über Random-Ports, was ein Problem mit Firewalls war, wenn man nicht komplett aufmachen wollte.