Trabajar con notificaciones de consulta
Se aplica a: 
SQL Server Azure SQL Managed Instance
Importante
SQL Server Native Client (SNAC) no se incluye con:
- SQL Server 2022 (16.x) y versiones posteriores
- SQL Server Management Studio 19 y versiones posteriores
Sql Server Native Client (SQLNCLI o SQLNCLI11) y el proveedor MICROSOFT OLE DB heredado para SQL Server (SQLOLEDB) no se recomiendan para el desarrollo de aplicaciones nuevas.
En el caso de los proyectos nuevos, use uno de los siguientes controladores:
Para SQLNCLI que se incluye como componente de motor de base de datos de SQL Server (versiones 2012 a 2019), consulte esta excepción de ciclo de vida de soporte técnico.
Las notificaciones de consulta se introdujeron en SQL Server 2005 (9.x) y SQL Server Native Client. Basado en la infraestructura de Service Broker introducida en SQL Server 2005 (9.x), las notificaciones de consulta permiten que las aplicaciones se notifiquen cuando los datos han cambiado. Esta característica resulta especialmente útil para las aplicaciones que proporcionan una caché de información de una base de datos, como una aplicación web, y necesitan recibir notificaciones si se modifican los datos de origen.
Las notificaciones de consulta permiten al usuario solicitar notificaciones dentro de un período de tiempo de espera especificado si se modifican los datos subyacentes de una consulta. La solicitud de notificación especifica las opciones de notificación, entre las que se incluyen el nombre de servicio, el texto del mensaje y el valor de tiempo de espera para el servidor. Las notificaciones se entregan a través de una cola de Service Broker que las aplicaciones pueden sondear de cara a las notificaciones disponibles.
La sintaxis de la cadena de opciones de notificación de consulta es la siguiente:
service=<service-name>[;(local database=<database> | broker instance=<broker instance>)]
Por ejemplo:
service=mySSBService;local database=mydb
Las suscripciones de notificación duran más que el proceso que las inicia, de modo que una aplicación puede crear una suscripción de notificación y, a continuación, terminar. La suscripción seguirá siendo válida y la notificación se producirá si los datos cambian dentro del período de tiempo de espera especificado al crear la suscripción. Una notificación se identifica mediante la consulta ejecutada, las opciones de notificación y el texto del mensaje, y puede cancelarse estableciendo su valor de tiempo de espera en cero.
Las notificaciones se envían una sola vez. Para obtener notificaciones continuas de cambios de datos, debe crearse una nueva suscripción ejecutando de nuevo la consulta después de procesar cada notificación.
Normalmente, las aplicaciones de SQL Server Native Client reciben notificaciones mediante el comando RECEIVE de Transact-SQL para leer las notificaciones de la cola asociadas al servicio especificado en las opciones de notificación.
Nota:
Los nombres de tabla deben calificarse en las consultas para las que se requiere notificación como, por ejemplo, dbo.myTable. Las tablas deben calificarse con nombres de dos partes. La suscripción no será válida si se usan nombres de tres o cuatro partes.
La infraestructura de notificación se crea a partir una característica de colas introducida en SQL Server 2005 (9.x). Normalmente, las notificaciones generadas en el servidor se envían a través de estas colas para procesarse más adelante.
Para poder usar notificaciones de consulta, debe haber una cola y un servicio en el servidor. Estos se pueden crear con Transact-SQL similar al siguiente:
CREATE QUEUE myQueue
CREATE SERVICE myService ON QUEUE myQueue
([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])
Nota:
El servicio debe usar el contrato predefinido http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification, tal y como se indicó anteriormente.
Proveedor OLE DB de SQL Server Native Client
El proveedor OLE DB de SQL Server Native Client admite notificaciones de consumidor en la modificación del conjunto de filas. El consumidor recibe notificaciones en cada fase de modificación del conjunto de filas y ante cualquiera intento de modificación.
Nota:
Pasar una consulta de notificaciones al servidor con ICommand::Execute es la única manera válida de suscribirse a las notificaciones de consulta con el proveedor OLE DB de SQL Server Native Client.
Conjunto de propiedades DBPROPSET_SQLSERVERROWSET
Para admitir notificaciones de consulta a través de OLE DB, SQL Server Native Client agrega las siguientes propiedades nuevas al conjunto de propiedades DBPROPSET_SQLSERVERROWSET.
| Nombre | Escribir | Descripción |
|---|---|---|
| SSPROP_QP_NOTIFICATION_TIMEOUT | VT_UI4 | Número de segundos que la notificación de consulta va a permanecer activa. El valor predeterminado es 432000 segundos (5 días). El valor mínimo es 1 segundo y el valor máximo es 2^31-1 segundos. |
| SSPROP_QP_NOTIFICATION_MSGTEXT | VT_BSTR | Texto del mensaje de la notificación. Lo define el usuario y no tiene ningún formato predefinido. De forma predeterminada, la cadena está vacía. Puede especificarse un mensaje usando de 1 a 2000 caracteres. |
| SSPROP_QP_NOTIFICATION_OPTIONS | VT_BSTR | Opciones de notificación de consulta. Se especifican en una cadena con la sintaxis nombre=valor. El usuario es responsable de la creación del servicio y de la lectura de las notificaciones fuera de la cola. El valor predeterminado es una cadena vacía. |
La suscripción de notificación se confirma siempre, independientemente de que la instrucción se haya ejecutado en una transacción de usuario o en una confirmación automática o de que la transacción en la que se haya ejecutado la instrucción se haya confirmado o revertido. La notificación del servidor se activa ante cualquiera de las siguientes condiciones de notificación no válida: cambio de esquema o datos subyacentes o cuando se alcanza el período de tiempo de espera, lo que ocurra antes. Los registros de notificación se eliminan en cuanto se activan. Por lo tanto, al recibir las notificaciones, la aplicación debe suscribirse de nuevo en caso de que deseen obtenerse actualizaciones posteriores.
Otra conexión o subproceso puede comprobar las notificaciones en la cola de destino. Por ejemplo:
WAITFOR (RECEIVE * FROM MyQueue); // Where MyQueue is the queue name.
Tenga en cuenta que SELECT * no elimina la entrada de la cola, pero RECEIVE * FROM sí. Esto detiene un subproceso del servidor si la cola está vacía. Si hay entradas en la cola en el momento de la llamada, se devuelven inmediatamente; de lo contrario, la llamada espera a que se realice una entrada en la cola.
RECEIVE * FROM MyQueue
Si la cola está vacía, esta instrucción devuelve inmediatamente un conjunto de resultados vacío; de lo contrario, devuelve todas las notificaciones en cola.
Si los valores SSPROP_QP_NOTIFICATION_MSGTEXT y SSPROP_QP_NOTIFICATION_OPTIONS son distintos de NULL y no están vacíos, el encabezado TDS de notificación de consulta que contiene las tres propiedades definidas anteriormente se envía al servidor cada vez que se ejecuta el comando. Si alguno de estos valores es NULL (o está vacío), el encabezado no se envía y se produce un error DB_E_ERRORSOCCURRED (o DB_S_ERRORSOCCURRED si ambas propiedades están marcadas como opcionales) y el valor de estado se establece en DBPROPSTATUS_BADVALUE. La validación se produce durante la ejecución y preparación. Del mismo modo, se genera DB_S_ERRORSOCCURED cuando las propiedades de notificación de consulta se establecen para las conexiones a versiones de SQL Server anteriores a SQL Server 2005 (9.x). En este caso, el valor de estado es DBPROPSTATUS_NOTSUPPORTED.
Iniciar una suscripción no garantiza que los mensajes posteriores se entregarán correctamente. Además, no se realiza ninguna comprobación de validez del nombre de servicio especificado.
Nota:
La preparación de instrucciones no hará nunca que se inicie una suscripción; esta acción solo se consigue mediante la ejecución de instrucciones, y las notificaciones de consulta no se verán afectadas por el uso de los servicios principales de OLE DB.
Para obtener más información sobre el conjunto de propiedades DBPROPSET_SQLSERVERROWSET, vea Propiedades y comportamientos del conjunto de filas.
Controlador ODBC de SQL Server Native Client
El controlador ODBC de SQL Server Native Client admite notificaciones de consulta mediante la adición de tres atributos nuevos a las funciones SQLGetStmtAttr y SQLSetStmtAttr :
SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT
SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS
SQL_SOPT_SS_QUERYNOTIFICATION_TIMEOUT
Si los valores de SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT y SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS son distintos de NULL, el encabezado TDS de notificación de consulta que contiene los tres atributos definidos anteriormente se enviará al servidor cada vez que se ejecute el comando. Si alguno de estos valores es NULL, el encabezado no se envía y se devuelve SQL_SUCCESS_WITH_INFO. La validación se produce en la función SQLPrepare, SqlExecDirect y SqlExecute, lo que produce un error si los atributos no son válidos. De forma similar, cuando estos atributos de notificación de consulta se establecen para las versiones de SQL Server anteriores a SQL Server 2005 (9.x), se produce un error en la ejecución con SQL_SUCCESS_WITH_INFO.
Nota:
La preparación de instrucciones no hará que se inicie nunca la suscripción; la ejecución de la instrucción sí que puede iniciar la suscripción.
Restricciones y casos especiales
Las notificaciones no admiten los siguientes tipos de datos:
text
ntext
image
Si se realiza una solicitud de notificación para una consulta que devuelve cualquiera de estos tipos, la notificación se activa inmediatamente, especificando que no fue posible la suscripción de notificación.
Cuando se realiza una solicitud de suscripción para un lote o procedimiento almacenado, se realiza una solicitud de suscripción independiente para cada instrucción del lote o procedimiento almacenado. Las instrucciones EXECUTE no registrarán ninguna notificación, pero enviarán la solicitud de notificación al comando ejecutado. Si se trata de un lote, el contexto se aplicará a las instrucciones ejecutadas y se aplicarán las mismas reglas descritas anteriormente.
El envío de una consulta para la notificación enviada por el mismo usuario en el mismo contexto de base de datos y tiene la misma plantilla, los mismos valores de parámetro, el mismo identificador de notificación y la misma ubicación de entrega de una suscripción activa existente, renovará la suscripción existente y restablecerá el nuevo tiempo de espera especificado. Esto significa que si se solicita notificación para consultas idénticas, solo se enviará una notificación. Esto se aplicaría a una consulta duplicada de un lote o si se llamó varias veces a una consulta de un procedimiento almacenado.