TFDEventAlerter HowTo

[lowmax_5]

Hi,
ich hatte es vor ein paar Wochen ebenfalls versucht unter MSSQL (2008) den TFDEventAlerter mit den Demos zum laufen zu bekommen und habe alle angegebenen Verfahren getestet. Leider vergebens- das Thema wurde daher erst einmal zurück gestellt. Es wurde nun mit Poll-Verfahren umgesetzt...

Unter Firebird hat es nach 5 Min. funktioniert . Nur die Portfreigabe/Firewall dabei beachten, da auf einem anderen Port <> 3050 kommuniziert wird.

[Uwe Raabe]

Könnte auch mit der verwendeten Delphi-Version zusammenhängen. Bei Sydney gab es da wohl ein paar Verbesserungen. Wenn ich Zeit finde, kann ich das Beispiel ja mal mit 10.4.2 und MSSQL ausprobieren.

[haentschman]

Moin...

Zitat:

Wenn ich Zeit finde, kann ich das Beispiel ja mal mit 10.4.2 und MSSQL ausprobieren.

Durch das Rumprobieren habe ich folgendes festgestellt:

Der Alerter legt mit jedem Register den Service und einen Queue (wahrscheinlich wegen der Einstellungen) mit jeweils einer GUID im Namen an. Diese werden beim Beenden wieder entfernt. Soweit so gut. Wenn das Programm aber "abgeschossen" oder über die IDE beendet wird, bleiben die Einträge in den Systemtabellen vorhanden.

Ist wahrscheinlich technisch nicht anders machbar...

PS: Ich hatte auch einmal nur den Namen ohne GUID gesehen...aber nur einmal.

Danke

PS:

Zitat:

Es wurde nun mit Poll-Verfahren umgesetzt..

...da werde ich mir auch einen Thread basteln der das erledigt. Ich würde das über eine Tabelle mit GUID, statt BigInt (da ist irgendwann Schluß), lösen. Die Datenmengen sind sogar hardgecodet in der Tabelle registriert. Der Thread schaut...Änderung GUID -> Event.
evt. Vorteil: kein Broker benötigt.

[himitsu]

Hast du es mal "manuell" versucht?
(CREATE EVENT NOTIFICATION)

Im Postgres hatten wir auch immer wieder mit dem TPgAlerter Problemchen,
also dass der oftmals einfach garnicht empfing, oder nach einem Reconnect die Arbeit ebenfalls einstellte (obwohl er darauf eigentlich reagieren sollte, so weit ich es im Code sah).

Am Ende hab ich nun im AfterConnect der Connection die Registrierung selbst gemacht (EXECUTE mit einem Registrieungs-Statement)
und dann es kommt nun im OnNotify der TPgConnecton an ... und das nun auch sehr zuverlässig. (bisher keine Probleme mehr bemerkt)

[braunbaer]

Zitat von Uwe Raabe:

Könnte auch mit der verwendeten Delphi-Version zusammenhängen. Bei Sydney gab es da wohl ein paar Verbesserungen. Wenn ich Zeit finde, kann ich das Beispiel ja mal mit 10.4.2 und MSSQL ausprobieren.

Das wäre super.
Ich sollte dies ebenfalls haben, bringe es aber einfach nicht zum laufen.
Das FDEventAlerter1Alert wird nicht getriggert.

Hoffe, du findest die Ursache...

[braunbaer]

Hat zu diesem Thema jemand eine Lösung?

Mir wäre das viel lieber, als alle paar Sekunden auf neue oder geänderte Daten zu prüfen.

Bin für jeden Tipp oder kleines Beispiel dankbar...

[haentschman]

Hallöle...

Zitat:

Mir wäre das viel lieber, als alle paar Sekunden auf neue oder geänderte Daten zu prüfen.

Das ganze war mir zu unsicher. Ich habe mich fürs "Polling" entschieden...

1. EventTypes

Delphi-Quellcode:

TRefreshDataType = (rdtComplete)
...

2. In der Datenbank eine Tabelle:

Code:

create table _Events
(
  ID int IDENTITY(1,1) NOT NULL,
  EventType int NOT NULL,
  EventName nvarchar(30) NOT NULL,
  EventCurrentGUID uniqueidentifier NOT NULL,
  CONSTRAINT Events_pk PRIMARY KEY CLUSTERED (ID ASC)
)
create index ixEventType on _Events (EventType)
GO

/* Events */
insert into _Events (EventType, EventName, EventCurrentGUID) values (0, 'Complete', NEWID())
GO

/* Trigger*/
create trigger TR_Complete on Complete for insert, update, delete as
begin
  update _Events set EventCurrentGUID = NEWID() where EventType = 0
end
GO

3. Ein Thread der das ganze überwacht (Auszug)

Delphi-Quellcode:

procedure TDatabaseEventThread.Execute;
var
  Qry: TFDQuery;

  procedure LoadEvents;
  begin
    Qry.Open;

    while not Qry.Eof do
    begin
      FGUIDDict.Add(Qry.FieldByName('EventType').AsInteger, TGuidField(Qry.FieldByName('EventCurrentGUID')).AsGUID);
      Qry.Next;
    end;
  end;

  procedure CheckEvents;
  var
    PairCurrent: TPair<Integer, TGUID>;
  begin
    FGUIDDictCurrent.Clear;
    Qry.Close;
    Qry.Open;

    while not Qry.Eof do
    begin
      FGUIDDictCurrent.Add(Qry.FieldByName('EventType').AsInteger, TGuidField(Qry.FieldByName('EventCurrentGUID')).AsGUID);
      Qry.Next;
    end;

    for PairCurrent in FGUIDDictCurrent do
    begin
      if FGUIDDict.ContainsKey(PairCurrent.Key) then // sicher ist sicher
      begin
        if not (FGUIDDict.Items[PairCurrent.Key] = PairCurrent.Value) then
        begin
          FGUIDDict.Items[PairCurrent.Key] := PairCurrent.Value; // zurückschreiben
          FLastEvent := TRefreshDataType(PairCurrent.Key); // DataType für Synchronisierung
          SyncOnDataChange;
        end;
      end;
    end;
  end;

begin
  inherited;
  Qry := FDatabase.CreateQuery;
  try
    Qry.SQL.Text := FDatabase.GetSQLByName('DB_EVENTS');

    LoadEvents;

    while not Self.Terminated do
    begin
      if FDatabase.IsEventDataChangeActive then
      begin
        CheckEvents;
      end;
      Sleep(1000);
    end;
  finally
    Qry.Free;
  end;
end;

Wenn ein Event eintritt, verteile ich das über eine Message an die Forms und die gibt das an die entsprechende Formlogik weiter. Die Formlogik kennt die Events auf die sie reagieren soll und aktualisiert ggf. die Datenmenge der Form.

...fertsch.