add lanaguage to code block (2)

Author: markingmyname

docs/database-engine/service-broker/broker-system-messages.md

@@ -33,7 +33,8 @@ When a remote service ends a dialog with an error or the local broker detects an
 The XML document that is contained in an error message uses the namespace **https://schemas.microsoft.com/SQL/ServiceBroker**. The root element of the document has the local name **Error**, and contains an element named **Code** and an element named **Message**. The **Code** element holds an integer value. The **Message** element holds the human-readable text of the message.
 
 For example, an error message generated by a service that processes expense reports might contain the following XML (reformatted for readability):
-```
+
+```xml
     <?xml version="1.0"?>
     <Error xmlns="https://schemas.microsoft.com/SQL/ServiceBroker">
       <Code>12</Code>
@@ -43,6 +44,7 @@ For example, an error message generated by a service that processes expense repo
       </Description>
     </Error>
 ```
+
 A receive operation receives an error message before any message for that dialog other than a dialog timer message. This occurs regardless of the order in which the error message arrived on the queue. When a queue has both a dialog timer message and an error message, a receive operation receives the dialog timer message before the error message.
 
 When an error message arrives for a dialog, the broker raises an error if an application tries to send a message on that dialog. However, an application can receive any remaining messages for the dialog, even after it receives an error message.

docs/database-engine/service-broker/conversation-priorities.md

@@ -252,7 +252,7 @@ This script specifies the priority level for the initiator conversation endpoint
 
 <!-- end list -->
 
-```
+```sql
     USE InitiatorDB;
     GO
     CREATE BROKER PRIORITY InitiatorToTargetPriority
@@ -271,7 +271,7 @@ This script specifies the priority level for the target conversation endpoint an
   - The SEND of the **ReplyMessage** from the **TargetService** to the **InitiatorQueue**.
 
 <!-- end list -->
-```
+```sql
     USE TargetDB;
     GO
     CREATE BROKER PRIORITY TargetToInitiatorPriority

docs/database-engine/service-broker/creating-a-remote-service-binding.md

@@ -29,11 +29,13 @@ When a conversation is initiated, Service Broker checks to see whether a remote
 Requests for remote service bindings use the message type **https://schemas.microsoft.com/SQL/ServiceBroker/BrokerConfigurationNotice/MissingRemoteServiceBinding**. The message is in XML format, and contains the name of the service for which remote service binding information should be available.
 
 For example, the following message is a request for a remote service binding to the service **http://Adventure-Works.com/Elsewhere**:
-```
+
+```xml
     <MissingRemoteServiceBinding xmlns="https://schemas.microsoft.com/SQL/ServiceBroker/BrokerConfigurationNotice/MissingRemoteServiceBinding">
       <SERVICE_NAME>http://Adventure-Works.com/Elsewhere</SERVICE_NAME>
     </MissingRemoteServiceBinding>
 ```
+
 The application that is defined in the BCN queue reads a **MissingRemoteServiceBinding** message from the queue. If the application can determine the appropriate user context for the target service, the application creates a remote service binding for the service and then ends the conversation. If the application cannot determine the remote service binding for the service, the application ends the conversation with an error.
 
 If the application ended the conversation with an error, Service Broker stores this response for 10 minutes. Service Broker will not send a **MissingRemoteServiceBinding** message for dialogs to the BCN service during this time. If a conversation is started after 10 minutes, Service Broker will send another **MissingRemoteServiceBinding** message to check whether a remote service binding has been created.

docs/database-engine/service-broker/handling-poison-messages.md

@@ -41,6 +41,7 @@ Consider the following questions when you decide how the application handles a p
 This Transact-SQL example shows a simple, stateless service that includes logic for handling poison messages. Before the stored procedure receives a message, the procedure saves the transaction. When the procedure cannot process a message, the procedure rolls the transaction back to the save point. The partial rollback returns the message to the queue while continuing to hold a lock on the conversation group for the message. Because the program continues to hold the conversation group lock, the program can update a table that maintains a list of failed messages without risk that another queue reader might process the message.
 
 The following example defines the activation stored procedure for the application:
+
 ```
     CREATE PROCEDURE ProcessExpenseReport
     AS
@@ -112,6 +113,7 @@ The following example defines the activation stored procedure for the applicatio
         END ;
     END ;
 ```
+
 The stored procedure TrackMessage tracks the number of times that a message has failed. When the message has not failed before, the procedure inserts a new counter for the message into the table ExpenseServiceFailedMessages. Otherwise, the procedure checks the counter for the number of times that the message failed. The procedure increments the counter when the counter is less than a predefined number. When the counter is greater than the predefined number, the procedure ends the conversation with an error and removes the counter for the conversation from the table.
 
 ```

docs/database-engine/service-broker/service-broker-dialog-security.md

@@ -31,9 +31,11 @@ Messages are encrypted on the network when the conversation uses either full sec
 Whether the conversation uses full security or anonymous security, the message body is encrypted with a symmetric session key that is generated for the specific conversation. Only the keys are encrypted with private key encryption using the certificate supplied for Dialog Security. Service Broker also performs a message integrity check to help detect message corruption or tampering.
 
 SQL Server creates a session key for a conversation that uses dialog security. To protect the session key while it is stored in the database, Service Broker encrypts the session key with the master key for the database. If a database master key is not available, messages for the conversation remain in the **transmission_status** with an error until a database master key is created, or until the conversation times out. Therefore, both databases that participate in the conversation must contain master keys, even when the databases are hosted in the same instance. If the initiating database does not contain a master key, the dialog will fail. If the target database does not contain a master key, messages remain in the transmission queue of the initiating database. The last transmission error for these messages indicates the reason that the messages cannot be delivered. Either use the ENCRYPTION = OFF parameter to create an unencrypted dialog, or use the following command to create a database master key:
-```
+
+```sql
     CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'
 ```
+
 For convenience, Service Broker allows secure conversations that remain within a single database to proceed regardless of whether the database contains a master key. While two different databases can be moved to different SQL Server instances during the lifetime of a conversation, a conversation within a single database always remains within that database. Therefore, the conversation can proceed.
 
 ### Full Security