Firebird Zeos ZibEventAlerter

[waldforest]

Hallo,
ich möchte würde gerne über einen Trigger mit Post_Event und ZIBEventAlerter die Aktualität der Client-Queries sicher stellen.
In meiner Datenbank habe ich zu jeder Tabelle einen Trigger, AFTER INSERT OR UPDATE OR DELETE, eingerichtet.

Code:

AFTER INSERT OR UPDATE OR DELETE POSITION 0
AS
BEGIN
   POST_EVENT 'KU_Tabelle_updated';
END

Wie hier im Forum gelesen habe ich die Autoregister, sowie Registered in die ZConnection gelegt.
Den ZibEventAlerter in mein Datenmodul.

Delphi-Quellcode:

procedure TDataModule1.con_to_DataAfterConnect(Sender: TObject);
begin
 zbvntlrtr1.Events.Clear;
 zbvntlrtr1.Events.Add('RE_Tabelle_updated');
 zbvntlrtr1.Events.Add('AR_Tabelle_updated');
 zbvntlrtr1.Events.Add('KU_Tabelle_updated');
 zbvntlrtr1.Events.Add('KO_Tabelle_updated');
 zbvntlrtr1.Events.Add('RU_Tabelle_updated');
 zbvntlrtr1.RegisterEvents;

Nun zu meinem Problem.
Solange ich nur ein oder zwei Events abfrage funktioniert alles einwandfrei, bei mehr als 2 werden nicht alle Events ausgewertet.
Mach ich hier etwas falsch ?
Kann man immer nur einen Event auswerten, muss ich in jedem Form einen eigenen EventAlerter einfügen und die abzufragenden Events immer wieder neu setzten ?

[mjustin]

Falls es keine Lösung gibt (Bug z.B.) wäre ein Workaround, nur noch ein einziges Event zu definieren und in einer Hilfs-Tabelle einen Eintrag zu erzeugen, den der Client nach dem Eintreffen des Events ausliest.

Das hat noch einen Zusatznutzen: wenn ein Client mal kurz abgemeldet (disconnected) war, kann er nach dem Verbindungsaufbau prüfen ob er Events verpasst hat.

Ganz besonders mit TClientDataSet ist es ja möglich, die Connection zu trennen und dennoch weiter die Grids und sonstigen datensensitiven Elemente anzuzeigen und zu bearbeiten. Nur hat man dann keine Möglicheit mehr, die Events zu empfangen.

[tsteinmaurer]

Hallo,

grundsätzlich wird der serverseitige Event nur nach einem COMMIT ausgelöst, d.h. ev. gibt es hier Unterschiede bei dir abhängig von der Tabelle. Auf der anderen Seite könnte es auch ein Bug in der Komponente sein. Die Komponente muss dahingehend robust sein, dass z.b. Events gequeued werden müssen, weil z.b. ein Update auf 100.000 Datensätze den triggerbasierten Event auch 100.000 feuert. Die EventAlerter Komponente muss damit zurecht kommen.

LG

[mjustin]

Zitat:

Zitat von tsteinmaurer (Beitrag 1256221)

Die Komponente muss dahingehend robust sein, dass z.b. Events gequeued werden müssen, weil z.b. ein Update auf 100.000 Datensätze den triggerbasierten Event auch 100.000 feuert.

Falls die 100.000 Updates innerhalb einer einzigen Transaktion erfolgten, sollte der Firebird Server nur den Count entsprechend mitliefern, wenn dieses Dokument es richtig beschreibt:
http://www.firebirdsql.org/file/docu...ird_events.pdf

Zitat:

Events ... carry a "count" - in case many events of the same type happened at once, the count shows how many were there

Frei übersetzt:
Events enthalten eine "Anzahl" - im Fall dass viele gleichartige Events auftraten, gibt "Anzahl", wieviele es waren.

[waldforest]

Hallo,
ich habe meine Trigger jetzt so umgestellt, dass dieser einen Eintrag in eine Hilfs-Tabelle erstellt.
Die Einträge kann ich ja dann in meiner Anwendung entsprechend einem einzelnen Trigger auswerte und weitere Schritte einleiten.

Ideal wäre, wenn Clientinfos des Auslösers mit eingetragen werden um zu erkennen ob der Tabelleneintrag überhaupt von Bedeutung ist. Denn wenn ich ihn selber ausgelöst hae, benötige ich ja keine weiteren ToDo´s.

Wie kann ich in Firebird hier einen Bezug herstellen ?

Gibts irgend ein Beispiel, wie so etwas realisiert wird ?

[mjustin]

Zitat:

Zitat von waldforest (Beitrag 1256230)

Wie kann ich in Firebird hier einen Bezug herstellen ?

Die Hilfstabelle kann auch die Client-ID speichern, damit kann der Client alle Sätze ausfiltern die er nicht benötigt da er selber der Auslöser war:

http://www.janus-software.com/fbmanu...=PSQL&topic=63

[tsteinmaurer]

@Michael: Du hast natürlich vollkommen Recht. Die Aggregation erfolgt bereits am Server! Trotzdem wird die Client-Komponente einen Queue-Mechanismus benötigen. Ich kann aus Erfahrung sagen, dass unzählige Zugriffskomponenten (IBX, IBObjects, IBDAC ...) in diesem Bereich immer wieder mal was gefixt haben, d.h. ganz so trivial ist das Ganze clientseitig nicht.

[waldforest]

Hallo,
mein Vorhaben ist doch etwas komplexer als ich es anfangs gedacht habe.

OK, ich strebe an, dies mit den Einträgen in der Hilfs-Tabelle zu regeln, welche ich je Client dann über eine Abfrage auswerte. Dabei stehe ich wieder vor einer Frage, zu der ich nicht fündig werde.
ALERTS_CURRENT_USER, OK, da ich nicht vor hatte bei meinen wenigen Netzusern eine eigen Berechtigungsstruktur zu hinterlegen denke ich reicht eine Abfrage der CURRENT_CONNECTION.
Wie erhalte ich diese Info in Delphi, spich aus meiner ZConnection aus ZEOS ?