Alertes des bases de données (FireDAC)

De RAD Studio
Aller à : navigation, rechercher

Remonter à Utilisation des commandes (FireDAC)


L'alerte SGBD fait référence à une notification ou une alerte de base de données envoyée par un déclencheur ou une procédure stockée de base de données à un client de base de données dans le but de lui notifier des événements.

Une alerte est identifiée par un nom et peut contenir des arguments supplémentaires. Les clients s'enregistrent à des alertes. Plusieurs clients peuvent s'enregistrer à une seule alerte et un seul client peut s'enregistrer à plusieurs alertes. Lorsqu'une alerte est signalée dans une base de données, tous les clients enregistrés sont avisés. Lorsqu'une alerte n'est plus utilisée, l'application se désenregistre de cette alerte.

Voici des exemples d'alertes standard :

  • Une modification des données d'une table. Dans ce cas, une application actualise un ensemble de données renvoyant ces données de table.
  • Une notification concernant une condition remplie dans les données.
  • Une notification envoyée à d'autres applications, signalant qu'une application spécifique va effectuer une tâche particulière, telle que l'archivage ou la sauvegarde de données.

Chaque SGBD implémente des alertes SGBD qui lui sont propres. Il n'existe aucune norme pour les mécanismes d'alerte.

Utilisation de TFDEventAlerter

FireDAC fournit des API d'alertes unifiées, telles que le composant TFDEventAlerter. Certains SGBD peuvent implémenter quelques mécanismes d'alerte de SGBD. Chaque objet TADEventAlerter écoute plusieurs alertes en indiquant leur nom dans la propriété TFDEventAlerter.Names et en utilisant un mécanisme unique spécifié par la propriété Options.Kind.

FireDAC écoute les alertes dans un thread en arrière-plan par le biais d'une connexion privée supplémentaire établie avec la base de données. Cette connexion supplémentaire est créée automatiquement par FireDAC pour chaque composant TFDEventAlerter. Lorsque l'application crée plusieurs objets TFDEventAlerter, pensez à utiliser les connexions mises en pool pour améliorer les performances.

Pour commencer à recevoir les alertes d'événements, indiquez dans la propriété TFDEventAlerter.Names les noms d'événements requis. Définissez Options.Kind sur le type d'alerte d'événement ou laissez cette propriété vide pour utiliser l'alerte par défaut. Indiquez le gestionnaire d'événement OnAlert déclenché lorsqu'un événement se produit et définissez la propriété Active sur True ou appelez la méthode Register. Pour ne plus recevoir les alertes d'événements, définissez la propriété Active sur False ou appelez Unregister.

Le gestionnaire d'événement OnAlert peut être appelé dans des contextes de thread principaux ou d'arrière-plan. ‎Utilisez la propriété Options.Synchronize pour contrôler ce comportement.

Remarque : L'application doit réduire l'exécution du gestionnaire de thread en arrière-plan.

L'application définit le dépassement du délai d'attente des alertes en spécifiant la propriété Options.Timeout. Lorsqu'il n'y a plus d'alertes pour une période spécifiée, le gestionnaire d'événement OnTimeout est appelé.

Par exemple, pour s'enregistrer à l'alerte "Customers" à l'aide du mécanisme "DBMS_ALERT" sur la base de données Oracle et du mécanisme Firebird standard, utilisez le code suivant : 

FDEventAlerter1.Names.Clear;
FDEventAlerter1.Names.Add('Customers');
case FDConnection1.RDBMSKind of
  mkOracle:    FDEventAlerter1.Options.Kind := 'DBMS_ALERT';
  mkInterbase: FDEventAlerter1.Options.Kind := 'Events';
end;
FDEventAlerter1.Options.Synchronize := True;
FDEventAlerter1.Options.Timeout := 10000;
FDEventAlerter1.OnAlter := DoAlert;
FDEventAlerter1.OnTimeout := DoTimeout;
FDEventAlerter1.Active := True;

// …

procedure TForm1.DoAlert(ASender: TFDCustomEventAlerter;
  const AEventName: String; const AArgument: Variant);
begin
  if CompareText(AEventName, 'Customers') = 0 then
    qryCustomers.Refresh;
end;

procedure TForm1.DoTimeout(ASender: TObject);
begin
  // …
end;

Pour Oracle, utilisez le code côté serveur suivant : 

CREATE OR REPLACE TRIGGER TR_CUSTOMERS
AFTER INSERT OR UPDATE OR DELETE ON CUSTOMERS
BEGIN
  SYS.DBMS_ALERT.SIGNAL('Customers', '123');
END;

Pour Firebird, utilisez le code suivant : 

CREATE TRIGGER TR_CUSTOMERS FOR CUSTOMERS
ACTIVE AFTER INSERT OR UPDATE OR DELETE
BEGIN
  POST_EVENT 'Customers';
END;

Mécanismes d'alerte des SGBD

Comme il a été noté plus haut, chaque SGBD implémente des alertes de base de données qui lui sont propres. Le type du mécanisme d'alerte est identifié par la valeur de la propriété TFDEventAlerterOptions.Kind. En l'absence de valeur spécifiée, le mécanisme par défaut est utilisé. Pour la plupart des mécanismes, les fonctionnalités côté client sont les mêmes, seules les fonctionnalités du côté de la base de données sont différentes.

Le tableau suivant présente le SGBD et ses mécanismes d'alerte qui sont supportés par les pilotes FireDAC :

SGBD Type d'alerte d'événement Description
Advantage Database Evénements (*) La fonctionnalité Evénements (Notifications) standard est utilisée. Pour lancer un événement, utilisez la procédure stockée sp_SignalEvent. Par exemple :

sp_SignalEvent('Customers', true, 0, '123');

Remarque : sp_SignalEvent ne peut être appelée qu'à partir d'une procédure stockée ou d'un déclencheur. Elle ne peut pas être appelée directement depuis la commande SQL.
Sybase SQL Anywhere Message (*) La fonctionnalité de l'instruction MESSAGE est utilisée. Pour lancer un événement, un message spécialement formaté de ce type : _FD_$$<nom_événement>[$$<argument>] doit être envoyé. Par exemple :

MESSAGE '_FD_$$Customers$$123'

Serveur DataSnap Rappels (*) Les rappels avancés DataSnap sont utilisés (pour plus d'informations, voir Delphi Labs : DataSnap XE - Callbacks). Le contenu de TFDEventAlerter.Names doit avoir l'un des formats suivants :
  • <nom_canal>. FireDAC enregistre un rappel pour le canal spécifié. Utilisez TDSAdminClient.BroadcastToChannel pour diffuser un événement à tous les composants TADEventAlerter enregistrés pour le canal spécifié.
  • <nom_canal>=<nom_rappel>. FireDAC enregistre un rappel avec le nom indiqué pour le canal spécifié. Si vous voulez lancer un événement, voir ci-dessus.
DB2 DBMS_ALERT (*) Le package DBMS_ALERT est utilisé. Avant d'être utilisé, un DBA doit exécuter GRANT EXECUTE ON DBMS_ALERT TO <utilisateur ou groupe>. Pour lancer un événement, utilisez l'appel DBMS_ALERT.SIGNAL. Par exemple :

CALL DBMS_ALERT.SIGNAL('Customers', '123');

DBMS_PIPE Le package DBMS_PIPE est utilisé. Avant d'être utilisé, un DBA doit exécuter GRANT EXECUTE ON DBMS_PIPE TO <utilisateur ou groupe>. Pour lancer un événement, utilisez l'appel DBMS_PIPE.SEND_MESSAGE. Par exemple :

BEGIN CALL DBMS_PIPE.PACK_MESSAGE(123); CALL DBMS_PIPE.SEND_MESSAGE('Customers'); END;

Firebird Evénements (*) Le mécanisme Firebird standard de notification d'événement est utilisé. Pour lancer un événement, utilisez l'instruction POST_EVENT <nom>. Par exemple :

EXECUTE BLOCK AS BEGIN POST_EVENT 'Customers'; END;

Informix DBMS_ALERT (*) Le package DBMS_ALERT est utilisé à partir du package de compatibilité externe. Pour lancer un événement, utilisez l'appel DBMS_ALERT_SIGNAL. Par exemple :

EXECUTE PROCEDURE DBMS_ALERT_SIGNAL('Customers', '123')

Interbase Evénements (*) Le mécanisme InterBase standard de notification d'événement est utilisé. Pour lancer un événement, utilisez l'instruction POST_EVENT <nom> à partir d'un déclencheur ou d'une procédure stockée. Le lancement côté client n'est pas pris en charge.
Microsoft SQL Server QueryNotifies (*) Le service de notification des mises à jour de requête est utilisé. Le contenu de TFDEventAlerter.Names doit avoir l'un des formats suivants :
  • CHANGE<index>=<message>;<SELECT query>. L'événement est déclenché lorsque les données renvoyées par la requête SELECT doivent être mises à jour et le <message> est renvoyé en tant que nom d'événement. Pour déclencher un événement, une instruction UPDATE sur les données sélectionnées doit être exécutée.
  • <message>. FireDAC crée la table _FD_EVENTS. L'événement est déclenché lorsque la valeur (VALUE) de la ligne NAME=<message> est mise à jour. Pour déclencher un événement, une instruction UPDATE doit être exécutée.

Vous pouvez également spécifier ces paramètres dans Names:

  • SERVICE=<nom>. Nom du service à utiliser. '?' signifie créer un service nommé de façon unique et le supprimer après utilisation.
  • QUEUE=<nom>. Nom de la file d'attente des messages à utiliser. '?' signifie créer une file d'attente nommée de façon unique et la supprimer après utilisation.
Remarque : Pour activer la notification des requêtes, exécutez la commande suivante :

ALTER DATABASE <nom_bd> SET ENABLE_BROKER

MongoDB Queue (*)

Utilise un curseur en queue (EN) sur une collection plafonnée (EN) pour alerter des insertions.

La propriété Names de l'alerte doit contenir une valeur unique un utilisant l'un des formats suivants pour indiquer la collection plafonnée cible :

  • <base de données>.<collection>
  • <base de données>.<collection>=<taille>
  • <collection>
  • <collection>=<taille>

Où :

  • <database> est le nom de la base de données qui contient la collection plafonnée cible. Le nom de la base de données par défaut est "test".
  • <collection> est le nom de la collection plafonnée cible.
  • Si la collection plafonnée cible n'existe pas, FireDAC crée une nouvelle collection plafonnée avec le nom de base de données, le nom de collection et le nombre de documents (<taille>) spécifiés. La taille par défaut est 1000 documents.

Quand une insertion se produit, votre gestionnaire pour l'événement OnAlert reçoit le document inséré comme une chaîne JSON (AArgument). AEventName est la valeur du champ "nom" du document inséré.

Oracle DBMS_ALERT (*) Le package DBMS_ALERT est utilisé. Avant d'être utilisé, un DBA doit exécuter GRANT EXECUTE ON DBMS_ALERT TO <utilisateur ou groupe>. Pour lancer un événement, utilisez l'appel DBMS_ALERT.SIGNAL. Par exemple :

BEGIN SYS.DBMS_ALERT.SIGNAL('Customers', '123'); END;

DBMS_PIPE Le package DBMS_PIPE est utilisé. Avant d'être utilisé, un DBA doit exécuter GRANT EXECUTE ON DBMS_PIPE TO <utilisateur ou groupe>. Pour lancer un événement, utilisez l'appel DBMS_PIPE.SEND_MESSAGE. Par exemple :

BEGIN SYS.DBMS_PIPE.PACK_MESSAGE(123); SYS.DBMS_PIPE.SEND_MESSAGE('Customers'); END;

QueryNotifies La fonctionnalité Continuous Query Notification (CQN) est l'implémentation Oracle de la fonctionnalité Notifications de changements de données. Pour de plus amples informations, voir Oracle CQN et Continuous Query Notification (EN).
PostgreSQL Notifie (*) Le mécanisme de notification d'événement standard est utilisé. Pour lancer un événement, utilisez l'instruction NOTIFY <nom>. PostgreSQL 9.0 prenant en charge les arguments de charge utile, utilisez NOTIFY <nom> [, <charge_utile>]. Par exemple :

NOTIFY Customers

SQLite Evénements (*) La fonction personnalisée POST_EVENT est utilisée. Pour lancer un événement, utilisez POST_EVENT(<name>, [arg1 [,arg2 [,arg3 [,arg4]]]]). Par exemple :

SELECT POST_EVENT('Customers', 123)

Note: L'astérisque marque le type d'alerte d'événement par défaut.

Voir aussi

Récupérée de « https://docwiki.embarcadero.com/RADStudio/Athens/f/index.php?title=Alertes_des_bases_de_données_(FireDAC)&oldid=204390 »