Utilisation de notifications de requêtes

S’applique à :SQL ServerAzure SQL Managed Instance

Les notifications de requête ont été introduites dans SQL Server 2005 (9.x) et SQL Server Native Client. Basées sur l’infrastructure Service Broker introduite dans SQL Server 2005 (9.x), les notifications de requête permettent aux applications d’être averties lorsque les données ont changé. Cette fonctionnalité est particulièrement utile pour les applications qui fournissent un cache d'informations à partir d'une base de données, par exemple une application Web, et qui doivent être notifiées en cas de modification des données sources.

Les notifications de requêtes vous permettent de demander une notification dans un délai d'attente spécifié lorsque les données sous-jacentes d'une requête sont modifiées. La demande de notification spécifie les options de notification, notamment le nom du service, le texte du message et la valeur du délai d'attente au serveur. Les notifications sont remises par l'intermédiaire d'une file d'attente Service Broker qui peut être interrogée par les applications pour détecter les notifications disponibles.

La syntaxe de la chaîne des options de notifications de requêtes est :

service=<service-name>[;(local database=<database> | broker instance=<broker instance>)]

Par exemple :

service=mySSBService;local database=mydb

La durée de vie des abonnements aux notifications est supérieure à celle des processus qui les initialisent. Cela s'explique par le fait qu'une application peut créer un abonnement aux notifications, puis se terminer. L'abonnement reste valide, et la notification a lieu si les données sont modifiées dans le délai d'attente imparti spécifié au moment de la création de l'abonnement. Une notification est identifiée par la requête exécutée, les options de notification et le texte du message, et peut être annulée en attribuant la valeur 0 au délai d'attente.

Les notifications sont envoyées une seule fois. Pour une notification continue des modifications de données, un nouvel abonnement doit être créé en exécutant à nouveau la requête une fois chaque notification traitée.

SQL Server Native Client applications reçoivent généralement des notifications à l’aide de la commande Transact-SQL RECEIVE pour lire les notifications de la file d’attente associée au service spécifié dans les options de notification.

L'infrastructure de notification repose sur une fonctionnalité de mise en file d'attente introduite dans SQL Server 2005 (9.x). En général, les notifications générées au niveau du serveur sont envoyées par l'intermédiaire de ces files d'attente pour un traitement ultérieur.

Pour utiliser des notifications de requêtes, une file d'attente et un service doivent exister sur le serveur. Ceux-ci peuvent être créés à l’aide de Transact-SQL comme suit :

CREATE QUEUE myQueue  
CREATE SERVICE myService ON QUEUE myQueue   
  
([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])  

Fournisseur OLE DB SQL Server Native Client

Le fournisseur OLE DB SQL Server Native Client prend en charge la notification au consommateur lors de la modification de l’ensemble de lignes. Le consommateur reçoit la notification à chaque phase de la modification de l'ensemble de lignes et à chaque tentative de modification.

Le jeu de propriétés DBPROPSET_SQLSERVERROWSET

Pour prendre en charge les notifications de requête via OLE DB, SQL Server Native Client ajoute les nouvelles propriétés suivantes au jeu de propriétés DBPROPSET_SQLSERVERROWSET.

L'abonnement aux notifications est toujours validé, que l'instruction ait été exécutée dans une transaction utilisateur ou en mode de validation automatique, ou que la transaction dans laquelle l'instruction s'est exécutée ait été validée ou restaurée. La notification du serveur est déclenchée lorsque l'une des conditions de notification non valides suivantes se produit : modification des données sous-jacentes ou du schéma ou expiration du délai d'attente imparti (selon l'opération qui se produit en premier). Les inscriptions de notification sont supprimées dès qu'elles sont déclenchées. Par conséquent, lorsque l'application reçoit des notifications, l'application doit encore s'abonner au cas où elle souhaiterait obtenir d'autres mises à jour.

Une autre connexion ou un autre thread peut vérifier la file d'attente de destination pour les notifications. Par exemple :

WAITFOR (RECEIVE * FROM MyQueue);   // Where MyQueue is the queue name.   

Notez que SELECT * ne supprime pas l'entrée de la file d'attente, contrairement à RECEIVE * FROM. Cela bloque un thread serveur si la file d'attente est vide. S'il existe des entrées de file d'attente au moment de l'appel, elles sont retournées immédiatement ; sinon, l'appel attend qu'une entrée de file d'attente soit soumise.

RECEIVE * FROM MyQueue  

Cette instruction retourne immédiatement un jeu de résultats vide si la file d'attente est vide ; sinon, elle retourne toutes les notifications de la file d'attente.

Si SSPROP_QP_NOTIFICATION_MSGTEXT et SSPROP_QP_NOTIFICATION_OPTIONS ne sont pas NULL et ne sont pas vides, l'en-tête TDS de notifications de requêtes contenant les trois propriétés définies plus haut sont envoyées au serveur avec chaque exécution de la commande. Si l'un d'eux est NULL (ou vide), l'en-tête n'est pas envoyé et DB_E_ERRORSOCCURRED est déclenché (ou DB_S_ERRORSOCCURRED si les propriétés sont toutes deux marquées comme étant facultatives) et la valeur d'état est DBPROPSTATUS_BADVALUE. La validation se produit dans la phase de préparation et d'exécution. De même, DB_S_ERRORSOCCURED est déclenché lorsque les propriétés de notification de requête sont définies pour les connexions à SQL Server versions antérieures SQL Server 2005 (9.x). La valeur d'état dans ce cas est DBPROPSTATUS_NOTSUPPORTED.

L'initialisation d'un abonnement ne garantit pas que les messages suivants soient correctement remis. De plus, aucun contrôle n'est effectué en termes de validité du nom du service spécifié.

Pour plus d’informations sur le jeu de propriétés DBPROPSET_SQLSERVERROWSET, consultez Propriétés et comportements de l’ensemble de lignes.

Pilote ODBC SQL Server Native Client

Le pilote ODBC SQL Server Native Client prend en charge les notifications de requête via l’ajout de trois nouveaux attributs aux fonctions SQLGetStmtAttr et SQLSetStmtAttr :

• SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT

• SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS

• SQL_SOPT_SS_QUERYNOTIFICATION_TIMEOUT

Si SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT et SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS ne sont pas NULL, l'en-tête TDS de notifications de requêtes contenant les trois attributs définis plus haut sera envoyé au serveur chaque fois que la commande est exécutée. Si l'un d'eux est Null, l'en-tête n'est pas envoyé, et SQL_SUCCESS_WITH_INFO est retourné. La validation se produit sur SQLPrepare Function, SqlExecDirect et SqlExecute, qui échouent tous si les attributs ne sont pas valides. De même, lorsque ces attributs de notification de requête sont définis pour SQL Server versions antérieures SQL Server 2005 (9.x), l’exécution échoue avec SQL_SUCCESS_WITH_INFO.

Cas particuliers et restrictions

Les types de données suivants ne sont pas pris en charge pour les notifications :

• text

• ntext

• image

Si une demande de notification est soumise pour une requête qui retourne l'un de ces types, la notification se déclenche immédiatement en spécifiant que l'abonnement aux notifications n'était pas possible.

Si une demande d'abonnement est soumise pour un lot ou une procédure stockée, une demande d'abonnement séparée est soumise pour chaque instruction exécutée dans le traitement ou la procédure stockée. Les instructions EXECUTE n'inscrivent aucune notification mais la demande de notification est envoyée à la commande exécutée. S'il s'agit d'un lot, le contexte est appliqué aux instructions exécutées et les mêmes règles décrites ci-dessus sont appliquées.

La soumission d’une requête pour notification qui a été envoyée par le même utilisateur dans le même contexte de base de données et qui a le même modèle, les mêmes valeurs de paramètre, le même ID de notification et le même emplacement de remise d’un abonnement actif existant, renouvelle l’abonnement existant, en réinitialisant le nouveau délai d’attente spécifié. Cela signifie que si une notification est demandée pour des requêtes identiques, une seule notification est envoyée. Cette situation concerne une requête dupliquée dans un lot ou une requête dans une procédure stockée qui a été appelée plusieurs fois.

Voir aussi

Fonctionnalités de SQL Server Native Client