瞭解定序與 Service Broker
Service Broker 是為使執行個體中具有不同定序組態的服務與應用程式能輕鬆、有效地通訊而設計的。主控傳送訊息之服務的資料庫可能不會使用與主控接收資訊之服務的資料庫相同的「定序」。因此，Service Broker 會使用一致的名稱定序，不論主控服務之資料庫的定序為何。為了從通訊處理中移除定序資訊，Service Broker 會使用逐一位元組的比較方式來比對服務名稱、合約名稱和訊息類型名稱。透過以位元組順序來比對名稱，Service Broker 可在沒有交換定序資訊之額外負擔的狀況下，為服務簡化正確交換訊息的處理。
逐一位元組比對是不考慮目前定序的有效二進位比較。由於這個原因，許多 Broker 服務都發現遵循 Naming Service Broker Objects 的建議很方便。不論主控目標服務的資料庫和主控起始服務的資料庫之間的定序有何不同，遵循這些指導方針和對所有名稱都區分大小寫的應用程式都應正確運作。
佇列定序考量
不論是 SQL Server 執行個體的預設定序，還是主控佇列之資料庫的預設定序，佇列都會使用一致的定序。如果佇列是包含資料庫中其他資料表 (例如用於維護狀態的資料表) 的 JOIN 陳述式之 SELECT 陳述式的目標 ，則可能會要求您明確指定比較的定序。
例如，使用訊息保留的應用程式在結束交談之前，可能需要保留部份交談的訊息。下列 Transact-SQL 程式碼範例會儲存給定交談之在 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
SELECT 陳述式會明確指定二進位比較用於比對訊息類型名稱。因為佇列不使用資料庫預設定序，所以比較 am.message_type_name = q.message_type_name 需要 COLLATE 子句才能成功。陳述式會指定二進位定序 (Latin1_General_BIN)，來比對 Service Broker 用於比對服務名稱之內部比較的行為。
應用程式定序考量
Service Broker 會將訊息主體作為二進位資料進行傳送，並且不修改此訊息的內容。如果應用程式交換區分定序的資料，則應用程式必須處理所有定序差異。交換文字的應用程式一般使用 Unicode 類型，以幫助將定序問題減到最少。