Merge pull request #5089 from MikeyBronowski/FormattingSQL

Formatting sql

Author: rothja

docs/2014/2014-toc/sql-server-transaction-locking-and-row-versioning-guide.md

@@ -225,7 +225,7 @@ GO
 
      A phantom read is a situation that occurs when two identical queries are executed and the collection of rows returned by the second query is different. The example below shows how this may occur. Assume the two transactions below are executing at the same time. The two SELECT statements in the first transaction may return different results because the INSERT statement in the second transaction changes the data used by both.  
 
-    ```  
+    ```sql  
     --Transaction 1  
     BEGIN TRAN;  
     SELECT ID FROM dbo.employee  
@@ -234,10 +234,9 @@ GO
     SELECT ID FROM dbo.employee  
     WHERE ID > 5 and ID < 10;  
     COMMIT;  
-  
     ```  
 
-    ```  
+    ```sql  
     --Transaction 2  
     BEGIN TRAN;  
     INSERT INTO dbo.employee  
@@ -566,7 +565,7 @@ GO
 
  To ensure a range scan query is serializable, the same query should return the same results each time it is executed within the same transaction. New rows must not be inserted within the range scan query by other transactions; otherwise, these become phantom inserts. For example, the following query uses the table and index in the previous illustration:  
 
-```  
+```sql  
 SELECT name  
     FROM mytable  
     WHERE name BETWEEN 'A' AND 'C';  
@@ -581,7 +580,7 @@ SELECT name
 
  If a query within a transaction attempts to select a row that does not exist, issuing the query at a later point within the same transaction has to return the same result. No other transaction can be allowed to insert that nonexistent row. For example, given this query:  
 
-```  
+```sql 
 SELECT name  
     FROM mytable  
     WHERE name = 'Bill';  
@@ -593,7 +592,7 @@ SELECT name
 
  When deleting a value within a transaction, the range the value falls into does not have to be locked for the duration of the transaction performing the delete operation. Locking the deleted key value until the end of the transaction is sufficient to maintain serializability. For example, given this DELETE statement:  
 
-```  
+```sql  
 DELETE mytable  
     WHERE name = 'Bob';  
 ```  
@@ -606,7 +605,7 @@ DELETE mytable
 
  When inserting a value within a transaction, the range the value falls into does not have to be locked for the duration of the transaction performing the insert operation. Locking the inserted key value until the end of the transaction is sufficient to maintain serializability. For example, given this INSERT statement:  
 
-```  
+```sql  
 INSERT mytable VALUES ('Dan');  
 ```  
 
@@ -970,7 +969,7 @@ deadlock-list
   
  These [!INCLUDE[tsql](../includes/tsql-md.md)] statements create test objects that are used in the examples that follow.  
   
-```  
+```sql  
 -- Create a test table.  
 CREATE TABLE TestTable  
     (col1        int);  
@@ -992,7 +991,7 @@ GO
 
  A `SELECT` statement is executed under a transaction. Because of the `HOLDLOCK` lock hint, this statement will acquire and retain an Intent shared (IS) lock on the table (for this illustration, row and page locks are ignored). The IS lock will be acquired only on the partition assigned to the transaction. For this example, it is assumed that the IS lock is acquired on partition ID 7.  
 
-```  
+```sql  
 -- Start a transaction.  
 BEGIN TRANSACTION  
     -- This SELECT statement will acquire an IS lock on the table.  
@@ -1005,7 +1004,7 @@ BEGIN TRANSACTION
 
  A transaction is started, and the `SELECT` statement running under this transaction will acquire and retain a shared (S) lock on the table. The S lock will be acquired on all partitions which results in multiple table locks, one for each partition. For example, on a 16-cpu system, 16 S locks will be issued across lock partition IDs 0-15. Because the S lock is compatible with the IS lock being held on partition ID 7 by the transaction in session 1, there is no blocking between transactions.  
 
-```  
+```sql  
 BEGIN TRANSACTION  
     SELECT col1  
         FROM TestTable  
@@ -1016,7 +1015,7 @@ BEGIN TRANSACTION
 
  The following `SELECT` statement is executed under the transaction that is still active under session 1. Because of the exclusive (X) table lock hint, the transaction will attempt to acquire an X lock on the table. However, the S lock that is being held by the transaction in session 2 will block the X lock at partition ID 0.  
 
-```  
+```sql  
 SELECT col1  
     FROM TestTable  
     WITH (TABLOCKX);  
@@ -1028,7 +1027,7 @@ SELECT col1
 
  A `SELECT` statement is executed under a transaction. Because of the `HOLDLOCK` lock hint, this statement will acquire and retain an Intent shared (IS) lock on the table (for this illustration, row and page locks are ignored). The IS lock will be acquired only on the partition assigned to the transaction. For this example, it is assumed that the IS lock is acquired on partition ID 6.  
 
-```  
+```sql  
 -- Start a transaction.  
 BEGIN TRANSACTION  
     -- This SELECT statement will acquire an IS lock on the table.  
@@ -1043,7 +1042,7 @@ BEGIN TRANSACTION
 
  On partition IDs 7-15 that the X lock has not yet reached, other transactions can continue to acquire locks.  
 
-```  
+```sql  
 BEGIN TRANSACTION  
     SELECT col1  
         FROM TestTable  
@@ -1308,7 +1307,7 @@ BEGIN TRANSACTION
 
  On session 1:  
 
-```  
+```sql  
 USE AdventureWorks2012;  -- Or the 2008 or 2008R2 version of the AdventureWorks database.  
 GO  
 
@@ -1331,7 +1330,7 @@ BEGIN TRANSACTION;
 
  On session 2:  
 
-```  
+```sql  
 USE AdventureWorks2012;  
 GO  
 
@@ -1353,7 +1352,7 @@ BEGIN TRANSACTION;
 
  On session 1:  
 
-```  
+```sql  
     -- Reissue the SELECT statement - this shows  
     -- the employee having 48 vacation hours.  The  
     -- snapshot transaction is still reading data from  
@@ -1365,7 +1364,7 @@ BEGIN TRANSACTION;
 
  On session 2:  
 
-```  
+```sql  
 -- Commit the transaction; this commits the data  
 -- modification.  
 COMMIT TRANSACTION;  
@@ -1374,7 +1373,7 @@ GO
 
  On session 1:  
 
-```  
+```sql  
     -- Reissue the SELECT statement - this still   
     -- shows the employee having 48 vacation hours  
     -- even after the other transaction has committed  
@@ -1409,7 +1408,7 @@ GO
 
  On session 1:  
 
-```  
+```sql  
 USE AdventureWorks2012;  -- Or any earlier version of the AdventureWorks database.  
 GO  
 
@@ -1436,7 +1435,7 @@ BEGIN TRANSACTION;
 
  On session 2:  
 
-```  
+```sql  
 USE AdventureWorks2012;  
 GO  
 
@@ -1459,7 +1458,7 @@ BEGIN TRANSACTION;
 
  On session 1:  
 
-```  
+```sql  
     -- Reissue the SELECT statement - this still shows  
     -- the employee having 48 vacation hours.  The  
     -- read-committed transaction is still reading data   
@@ -1473,7 +1472,7 @@ BEGIN TRANSACTION;
 
  On session 2:  
 
-```  
+```sql  
 -- Commit the transaction.  
 COMMIT TRANSACTION;  
 GO  
@@ -1482,7 +1481,7 @@ GO
 
  On session 1:  
 
-```  
+```sql  
     -- Reissue the SELECT statement which now shows the   
     -- employee having 40 vacation hours.  Being   
     -- read-committed, this transaction is reading the   
@@ -1512,7 +1511,7 @@ GO
 
  The following [!INCLUDE[tsql](../includes/tsql-md.md)] statement enables READ_COMMITTED_SNAPSHOT:  
 
-```  
+```sql  
 ALTER DATABASE AdventureWorks2012  
     SET READ_COMMITTED_SNAPSHOT ON;  
 ```  
@@ -1521,7 +1520,7 @@ ALTER DATABASE AdventureWorks2012
 
  The following [!INCLUDE[tsql](../includes/tsql-md.md)] statement will enable ALLOW_SNAPSHOT_ISOLATION:  
 
-```  
+```sql  
 ALTER DATABASE AdventureWorks2012  
     SET ALLOW_SNAPSHOT_ISOLATION ON;  
 ```  
@@ -1551,7 +1550,7 @@ ALTER DATABASE AdventureWorks2012
 
 -   Read-committed that uses row versioning by setting the `READ_COMMITTED_SNAPSHOT` database option to `ON` as shown in the following code example:  
 
-    ```  
+    ```sql  
     ALTER DATABASE AdventureWorks2012  
         SET READ_COMMITTED_SNAPSHOT ON;  
     ```  
@@ -1560,14 +1559,14 @@ ALTER DATABASE AdventureWorks2012
 
 -   Snapshot isolation by setting the `ALLOW_SNAPSHOT_ISOLATION` database option to `ON` as shown in the following code example:  
 
-    ```  
+    ```sql  
     ALTER DATABASE AdventureWorks2012  
         SET ALLOW_SNAPSHOT_ISOLATION ON;  
     ```  
 
      A transaction running under snapshot isolation can access tables in the database that have been enabled for snapshot. To access tables that have not been enabled for snapshot, the isolation level must be changed. For example, the following code example shows a `SELECT` statement that joins two tables while running under a snapshot transaction. One table belongs to a database in which snapshot isolation is not enabled. When the `SELECT` statement runs under snapshot isolation, it fails to execute successfully.  
 
-    ```  
+    ```sql  
     SET TRANSACTION ISOLATION LEVEL SNAPSHOT;  
     BEGIN TRAN  
         SELECT t1.col5, t2.col5  
@@ -1578,7 +1577,7 @@ ALTER DATABASE AdventureWorks2012
 
      The following code example shows the same `SELECT` statement that has been modified to change the transaction isolation level to read-committed. Because of this change, the `SELECT` statement executes successfully.  
 
-    ```  
+    ```sql  
     SET TRANSACTION ISOLATION LEVEL SNAPSHOT;  
     BEGIN TRAN  
         SELECT t1.col5, t2.col5  
@@ -1612,7 +1611,7 @@ ALTER DATABASE AdventureWorks2012
 
      For example, a database administrator executes the following `ALTER INDEX` statement.  
 
-    ```  
+    ```sql  
     USE AdventureWorks2012;  
     GO  
     ALTER INDEX AK_Employee_LoginID  
@@ -1642,7 +1641,7 @@ ALTER DATABASE AdventureWorks2012
 
  To determine the current LOCK_TIMEOUT setting, execute the @@LOCK_TIMEOUT function:  
 
-```  
+```sql  
 SELECT @@lock_timeout;  
 GO  
 ```  
@@ -1665,7 +1664,7 @@ GO
 
  The following example sets the `SERIALIZABLE` isolation level:  
 
-```  
+```sql  
 USE AdventureWorks2012;  
 GO  
 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;  
@@ -1682,7 +1681,7 @@ GO
 
  To determine the transaction isolation level currently set, use the `DBCC USEROPTIONS` statement as shown in the following example. The result set may vary from the result set on your system.  
 
-```  
+```sql  
 USE AdventureWorks2012;  
 GO  
 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;  
@@ -1730,7 +1729,7 @@ GO
 
  As shown in the following example, if the transaction isolation level is set to `SERIALIZABLE`, and the table-level locking hint `NOLOCK` is used with the `SELECT` statement, key-range locks typically used to maintain serializable transactions are not taken.  
 
-```  
+```sql  
 USE AdventureWorks2012;  
 GO  
 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;  
@@ -1787,7 +1786,7 @@ GO
 
  The following example shows the intended use of nested transactions. The procedure `TransProc` enforces its transaction regardless of the transaction mode of any process that executes it. If `TransProc` is called when a transaction is active, the nested transaction in `TransProc` is largely ignored, and its INSERT statements are committed or rolled back based on the final action taken for the outer transaction. If `TransProc` is executed by a process that does not have an outstanding transaction, the COMMIT TRANSACTION at the end of the procedure effectively commits the INSERT statements.  
 
-```  
+```sql  
 SET QUOTED_IDENTIFIER OFF;  
 GO  
 SET NOCOUNT OFF;  

docs/2014/analysis-services/multidimensional-models/authorizing-access-to-objects-and-operations-analysis-services.md

@@ -34,7 +34,7 @@ ms.author: owend
 
 2.  Type the following query and press F5 to execute:  
 
-    ```  
+    ```sql  
     Select * from $SYSTEM.DBSCHEMA_CATALOGS  
     ```  
 

docs/2014/analysis-services/relational-query-designer-ssas.md

@@ -213,7 +213,7 @@ ms.author: owend
 #### Example  
  The following query returns the list of names from a table named `ContactType`.  
 
-```  
+```sql  
 SELECT Name FROM ContactType  
 ```  
 
@@ -236,7 +236,7 @@ SELECT Name FROM ContactType
 #### Example  
  The following query calls the a stored procedure named `uspGetWhereUsedProductID`. When the stored procedure has input parameters you must provide parameter values when you run the query.  
 
-```  
+```sql  
 uspGetWhereUsedProductID  
 ```  
 

docs/2014/data-quality-services/backing-up-and-restoring-dqs-databases.md

@@ -55,12 +55,11 @@ ms.author: lle
 
 11. In the Query Editor window, copy the following SQL statements, and replace *\<PASSWORD>* with the password that you provided during the DQS installation for the database master key:  
 
-    ```  
+    ```sql  
     USE [DQS_MAIN]  
     GO  
     EXECUTE [internal_core].[RestoreDQDatabases] '<PASSWORD>'  
     GO  
-  
     ```  
 
 12. Press F5 to execute the statements. Check the **Results** pane to verify that the statements have executed successfully.  

docs/2014/data-quality-services/configure-advanced-settings-for-dqs-log-files.md

@@ -32,8 +32,8 @@ ms.author: lle
 ##  <a name="DQSServer"></a> Configure Data Quality Server Log Settings  
  The [!INCLUDE[ssDQSServer](../includes/ssdqsserver-md.md)] log settings are present in an XML format in the **VALUE** column of the **ServerLogging** row in the A_CONFIGURATION table in the DQS_MAIN database. You can run the following SQL query to view the configuration information:  
 
-```  
-select * from DQS_MAIN.dbo.A_CONFIGURATION where NAME='ServerLogging'  
+```sql  
+select * from DQS_MAIN.dbo.A_CONFIGURATION where NAME='ServerLogging'; 
 ```  
 
  You must update the appropriate information in the **VALUE** column of the **ServerLogging** row to change the configuration settings for [!INCLUDE[ssDQSServer](../includes/ssdqsserver-md.md)] logging. In this example, we will update the [!INCLUDE[ssDQSServer](../includes/ssdqsserver-md.md)] log settings to set the rolling file size limit to 25000 KB (the default is 20000 KB).  
@@ -44,7 +44,7 @@ select * from DQS_MAIN.dbo.A_CONFIGURATION where NAME='ServerLogging'
 
 3.  In the Query Editor window, copy the following SQL statements:  
 
-    ```  
+    ```sql  
     -- Begin the transaction.  
     BEGIN TRAN  
     GO  
@@ -90,14 +90,13 @@ select * from DQS_MAIN.dbo.A_CONFIGURATION where NAME='ServerLogging'
 
 5.  To apply changes done to the [!INCLUDE[ssDQSServer](../includes/ssdqsserver-md.md)] logging configuration, you must run the following Transact-SQL statements. Open a new Query Editor window, and paste the following Transact-SQL statements:  
 
-    ```  
+    ```sql  
     USE [DQS_MAIN]  
     GO  
     DECLARE @return_value int  
     EXEC @return_value = [internal_core].[RefreshLogSettings]  
     SELECT 'Return Value' = @return_value  
     GO  
-  
     ```  
 
 6.  Press F5 to execute the statements. Check the **Results** pane to verify that the statements have executed successfully.