Descripción de la intercalación y Service Broker
Service Broker está diseñado para permitir que los servicios y las aplicaciones de instancias con configuraciones de intercalación distintas se comuniquen de forma sencilla y eficaz. Puede que la base de datos que aloja un servicio que envía un mensaje no utilice la misma intercalación que la base de datos que aloja el servicio que recibe el mensaje. Por tanto, Service Broker utiliza una intercalación coherente para nombres, independientemente de la intercalación de la base de datos que aloja el servicio. Para quitar la información de intercalación del proceso de comunicación, Service Broker utiliza una comparación byte a byte en los nombres de servicio, los nombres de contrato y los nombres de tipo de mensaje. Al hacer coincidir los nombres como secuencias de bytes, Service Broker facilita a los servicios el intercambio correcto de mensajes sin la sobrecarga de intercambiar información de intercalación.
La coincidencia byte a byte es realmente una comparación binaria que no tiene en cuenta la intercalación actual. Por este motivo, muchos servicios de broker encuentran cómodo seguir las recomendaciones de Asignación de nombres a objetos de Service Broker. Una aplicación que sigue estas directrices y trata todos los nombres con distinción de mayúsculas y minúsculas debería funcionar correctamente, independientemente de las diferencias de intercalación entre la base de datos que aloja el servicio de destino y la base de datos que aloja el servicio iniciador.
Consideraciones sobre la intercalación en las colas
Las colas utilizan una intercalación coherente independientemente de la intercalación predeterminada de la instancia de SQL Server o de la intercalación predeterminada de la base de datos que aloja la cola. Si una cola es el destino de una instrucción SELECT que incluye una instrucción JOIN con otra tabla de la base de datos, como una tabla utilizada para mantener el estado, es posible que deba especificar explícitamente la intercalación para la comparación.
Por ejemplo, una aplicación que utiliza la retención de mensajes puede necesitar conservar algunos mensajes de una conversación antes de que la aplicación finalice la conversación. El siguiente ejemplo de código Transact-SQL guarda todos los mensajes de una conversación dada que tienen un nombre de tipo de mensaje en la tabla AuditedMessageTypes.
IF @messageTypeName =
'https://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
INSERT INTO dbo.AuditRecord
SELECT q.message_type_name, q.message_body
FROM dbo.ApplicationQueue AS q
JOIN dbo.AuditedMessageTypes AS am ON
am.message_type_name = q.message_type_name
COLLATE Latin1_General_BIN
AND
q.conversation_handle = @conversationHandle
END CONVERSATION @conversationHandle
END
La instrucción SELECT especifica explícitamente una comparación binaria para hacer coincidir los nombres de tipo de mensaje. Dado que una cola no utiliza la intercalación predeterminada de la base de datos, la cláusula COLLATE es necesaria para que la comparación am.message_type_name = q.message_type_name sea correcta. La instrucción especifica una intercalación binaria, Latin1_General_BIN, para coincidir con el comportamiento de la comparación interna que utiliza Service Broker para hacer coincidir los nombres de servicio.
Consideraciones sobre la intercalación en la aplicación
Service Broker transmite el cuerpo del mensaje como datos binarios y no modifica su contenido. Si las aplicaciones intercambian datos que distinguen la intercalación, deben controlar cualquier diferencia de intercalación. Las aplicaciones que intercambian texto suelen utilizar tipos Unicode para ayudar a reducir los problemas de intercalación.