Merge remote-tracking branch 'upstream/release-2019-cu12' into release-2019-cu

Author: DaniBunny

docs/connect/odbc/linux-mac/install-microsoft-odbc-driver-sql-server-macos.md

@@ -1,7 +1,7 @@
 ---
 title: Install the Microsoft ODBC driver for SQL Server (macOS)
 description: Learn how to install the Microsoft ODBC Driver for SQL Server on macOS clients to enable database connectivity.
-ms.date: 07/30/2021
+ms.date: 08/02/2021
 ms.prod: sql
 ms.prod_service: connectivity
 ms.technology: connectivity
@@ -19,7 +19,7 @@ This article explains how to install the Microsoft ODBC Driver for SQL Server on
 This article provides commands for installing the ODBC driver from the bash shell. If you want to download the packages directly, see [Download ODBC Driver for SQL Server](../download-odbc-driver-for-sql-server.md).
 
 > [!Note]
-> The Microsoft ODBC driver for SQL Server on macOS is only supported on the x64 architecture. The Apple M1 is not supported.
+> The Microsoft ODBC driver for SQL Server on macOS is only supported on the x64 architecture through version 17.7. The Apple M1 (ARM64) is supported starting with version 17.8. The architecture will be detected and the correct package will be automatically installed by the Homebrew formula. If your command prompt is running in x64 emulation mode on the M1, the x64 package will be installed. If you're not running in emulation mode in your command prompt, the ARM64 package will be installed.
 
 ## Microsoft ODBC 17
 

docs/connect/odbc/linux-mac/release-notes-odbc-sql-server-linux-mac.md

@@ -1,8 +1,8 @@
 ---
-title: "Release Notes ODBC Driver for SQL Server on Linux and macOS"
+title: Release Notes ODBC Driver for SQL Server on Linux and macOS
 description: "Learn what's new and changed in released versions of the Microsoft ODBC Driver for SQL Server."
 ms.custom: ""
-ms.date: "07/30/2021"
+ms.date: 08/02/2021
 ms.prod: sql
 ms.prod_service: connectivity
 ms.reviewer: v-daenge
@@ -36,6 +36,7 @@ GeneMi.  2019/04/03.
 | New item | Details |
 | :------- | :------ |
 | New distributions supported. | Ubuntu 21.04, Alpine 3.13 |
+| Support for Apple M1 ARM64 hardware | See [Install the ODBC driver (macOS)](install-microsoft-odbc-driver-sql-server-macos.md). |
 | Replication option added to the connection string | See [DSN and Connection String Attributes and Keywords](../dsn-connection-string-attribute.md). |
 | KeepAlive and KeepAliveInterval options added to the connection string | See [DSN and Connection String Attributes and Keywords](../dsn-connection-string-attribute.md). |
 | Bug fixes. | [Bug fixes](../bug-fixes.md). |

docs/database-engine/availability-groups/windows/automatic-seeding-secondary-replicas.md

@@ -88,7 +88,7 @@ CREATE AVAILABILITY GROUP [<AGName>]
 WITH (
   ENDPOINT_URL = N'TCP://Primary_Replica.Contoso.com:5022', 
   FAILOVER_MODE = AUTOMATIC, 
-  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
+  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
 ),
   N'Secondary_Replica' WITH (
     ENDPOINT_URL = N'TCP://Secondary_Replica.Contoso.com:5022', 

docs/database-engine/availability-groups/windows/change-the-availability-mode-of-an-availability-replica-sql-server.md

@@ -48,8 +48,11 @@ You must be connected to the server instance that hosts the primary replica.
 2.  Use the [ALTER AVAILABILITY GROUP](../../../t-sql/statements/alter-availability-group-transact-sql.md) statement, as the following example:  
 
      ```sql
-     ALTER AVAILABILITY GROUP *group_name* MODIFY REPLICA ON '*server_name*'  
-     WITH ( AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT , FAILOVER_MODE = MANUAL );  
+     ALTER AVAILABILITY GROUP [<availability_group_name>] MODIFY REPLICA ON '*server_name*'  
+     WITH ( AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
+	 
+     ALTER AVAILABILITY GROUP [<availability_group_name>] MODIFY REPLICA ON '*server_name*'  
+     WITH ( FAILOVER_MODE = MANUAL );  
      ```
 
      Where *group_name* is the name of the availability group and *server_name* is the name of the server instance that hosts the replica to be modified.  

docs/database-engine/availability-groups/windows/create-an-availability-group-transact-sql.md

@@ -226,7 +226,7 @@ ms.author: chadam
 
      The following code example creates a transaction log backup on MyDb1 and on MyDb2.  
 
-    ```sql  
+    ```sql
     -- On the server instance that hosts the primary replica,   
     -- Backup the transaction log on each primary database:  
     BACKUP LOG MyDb1   
@@ -236,7 +236,7 @@ ms.author: chadam
   
     BACKUP LOG MyDb2   
     TO DISK = N'\\FILESERVER\SQLbackups\MyDb2.bak'   
-        WITHNOFORMAT;  
+        WITH NOFORMAT;  
     GO
     ```  
 
@@ -409,7 +409,7 @@ GO
   
 BACKUP LOG MyDb2   
 TO DISK = N'\\FILESERVER\SQLbackups\MyDb2.bak'   
-    WITHNOFORMAT  
+    WITH NOFORMAT  
 GO  
   
 -- Restore the transaction log on each secondary database,  

docs/database-engine/availability-groups/windows/secondary-replica-connection-redirection-always-on-availability-groups.md

@@ -90,7 +90,7 @@ The following transact-SQL script creates this AG. In this example, Each replica
 CREATE AVAILABILITY GROUP MyAg   
      WITH ( CLUSTER_TYPE =  NONE )  
    FOR   
-     DATABASE  <Database1>   
+     DATABASE  [<Database1>]   
    REPLICA ON   
       'COMPUTER01' WITH   
          (  
@@ -100,8 +100,8 @@ CREATE AVAILABILITY GROUP MyAg
          SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,   
             READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01.<domain>.<tld>:1433' ),
          PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
-            READ_ONLY_ROUTING_LIST = (COMPUTER02, COMPUTER03),
-            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER01.<domain>.<tld>:1433' )   
+            READ_ONLY_ROUTING_LIST = ('COMPUTER02', 'COMPUTER03'),
+            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER01.<domain>.<tld>:1433' ),   
          SESSION_TIMEOUT = 10  
          ),   
       'COMPUTER02' WITH   
@@ -112,8 +112,8 @@ CREATE AVAILABILITY GROUP MyAg
          SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,   
             READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02.<domain>.<tld>:1433' ),  
          PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
-            READ_ONLY_ROUTING_LIST = (COMPUTER01, COMPUTER03),  
-            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER02.<domain>.<tld>:1433' )   
+            READ_ONLY_ROUTING_LIST = ('COMPUTER01', 'COMPUTER03'),  
+            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER02.<domain>.<tld>:1433' ),
          SESSION_TIMEOUT = 10  
          ),   
       'COMPUTER03' WITH   
@@ -124,8 +124,8 @@ CREATE AVAILABILITY GROUP MyAg
          SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,   
             READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03.<domain>.<tld>:1433' ),  
          PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
-            READ_ONLY_ROUTING_LIST = (COMPUTER01, COMPUTER02),  
-            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER03.<domain>.<tld>:1433' )  
+            READ_ONLY_ROUTING_LIST = ('COMPUTER01', 'COMPUTER02'),  
+            READ_WRITE_ROUTING_URL = 'TCP://COMPUTER03.<domain>.<tld>:1433' ),
          SESSION_TIMEOUT = 10  
          );
 GO  

docs/machine-learning/deploy/modify-r-python-code-to-run-in-sql-server.md

@@ -72,12 +72,25 @@ How much you change your code depends on whether you intend to submit the code f
 
 + When running code in a stored procedure, you can pass through multiple **scalar** inputs. For any parameters that you want to use in the output, add the **OUTPUT** keyword.
 
-  For example, the following scalar input `@model_name` contains the model name, which is also output in its own column in the results:
+  For example, the following scalar input `@model_name` contains the model name, which is also later modified by the R script, and output in its own column in the results:
 
   ```sql
-  EXECUTE sp_execute_external_script @model_name = "DefaultModel" OUTPUT
-	,@language = N'R'
-	,@script = N'R code here'
+  -- declare a local scalar variable which will be passed into the R script
+  DECLARE @local_model_name AS NVARCHAR (50) = 'DefaultModel';
+
+  -- The below defines an OUTPUT variable in the scope of the R script, called model_name
+  -- Syntactically, it is defined by using the @model_name name. Be aware that the sequence
+  -- of these parameters is very important. Mandatory parameters to sp_execute_external_script
+  -- must appear first, followed by the additional parameter definitions like @params, etc.
+  EXECUTE sp_execute_external_script @language = N'R', @script = N'
+    model_name <- "Model name from R script"
+    OutputDataSet <- data.frame(InputDataSet$c1, model_name)'
+    , @input_data_1 = N'SELECT 1 AS c1'
+    , @params = N'@model_name nvarchar(50) OUTPUT'
+    , @model_name = @local_model_name OUTPUT;
+
+  -- optionally, examine the new value for the local variable:
+  SELECT @local_model_name;
   ```
 
 + Any variables that you pass in as parameters of the stored procedure [sp_execute_external_script](../../relational-databases/system-stored-procedures/sp-execute-external-script-transact-sql.md) must be mapped to variables in the code. By default, variables are mapped by name. All columns in the input dataset must also be mapped to variables in the script.

docs/relational-databases/indexes/columnstore-indexes-data-loading-guidance.md

@@ -79,15 +79,17 @@ If you are loading data only to stage it before running more transformations, lo
  A common pattern for data load is to load the data into a staging table, do some transformation and then load it into the target table using the following command  
 
 ```sql  
-INSERT INTO <columnstore index>  
-SELECT <list of columns> FROM <Staging Table>  
+INSERT INTO [<columnstore index>]
+SELECT col1 /* include actual list of columns in place of col1*/
+FROM [<Staging Table>]
 ```  
 
  This command loads the data into the columnstore index in similar ways to BCP or Bulk Insert but in a single batch. If the number of rows in the staging table < 102400, the rows are loaded into a delta rowgroup otherwise the rows are directly loaded into compressed rowgroup. One key limitation was that this `INSERT` operation was single threaded. To load data in parallel, you could create multiple staging table or issue `INSERT`/`SELECT` with non-overlapping ranges of rows from the staging table. This limitation goes away with [!INCLUDE[sssql16-md](../../includes/sssql16-md.md)]. The command below loads the data from staging table in parallel but you will need to specify `TABLOCK`. You may find this contradictory to what was said earlier with bulkload but the key difference is the parallel data load from the staging table is executed under the same transaction.
 
 ```sql  
-INSERT INTO <columnstore index> WITH (TABLOCK) 
-SELECT <list of columns> FROM <Staging Table>  
+INSERT INTO [<columnstore index>] WITH (TABLOCK) 
+SELECT col1 /* include actual list of columns in place of col1*/
+FROM [<Staging Table>]
 ```  
 
  There are following optimizations available when loading into clustered columnstore index from staging table:
@@ -101,7 +103,7 @@ SELECT <list of columns> FROM <Staging Table>
 *Trickle insert* refers to the way individual rows move into the columnstore index. Trickle inserts use the [INSERT INTO](../../t-sql/statements/insert-transact-sql.md) statement. With trickle insert, all of the rows go to the deltastore. This is useful for small numbers of rows, but not practical for large loads.
 
 ```sql  
-INSERT INTO <table-name> VALUES (<set of values>)  
+INSERT INTO [<table-name>] VALUES ('some value' /*replace with actual set of values*/)  
 ```  
 
  > [!NOTE]
@@ -110,13 +112,13 @@ INSERT INTO <table-name> VALUES (<set of values>)
  Once the rowgroup contains 1,048,576 rows, the delta rowgroup us marked closed but it is still available for queries and update/delete operations but the newly inserted rows go into an existing or newly created deltastore rowgroup. There is a background thread *Tuple Mover (TM)* that compresses the closed delta rowgroups periodically every 5 minutes or so. You can explicitly invoke the following command to compress the closed delta rowgroup  
 
 ```sql  
-ALTER INDEX <index-name> on <table-name> REORGANIZE  
+ALTER INDEX [<index-name>] on [<table-name>] REORGANIZE  
 ```  
 
  If you want force a delta rowgroup closed and compressed, you can execute the following command. You may want run this command if you are done loading the rows and don't expect any new rows. By explicitly closing and compressing the delta rowgroup, you can save storage further and improve the analytics query performance. A best practice is to invoke this command if you  don't expect new rows to be inserted.  
 
 ```sql  
-ALTER INDEX <index-name> on <table-name> REORGANIZE with (COMPRESS_ALL_ROW_GROUPS = ON)  
+ALTER INDEX [<index-name>] on [<table-name>] REORGANIZE with (COMPRESS_ALL_ROW_GROUPS = ON)  
 ```  
 
 ## How loading into a partitioned table works