Merge pull request #110024 from Kat-Campise/rebrand_sqldw_v4

rebrand sqldw third 6

Author: GitHubber17

articles/synapse-analytics/sql-data-warehouse/sql-data-warehouse-develop-transactions.md

@@ -1,6 +1,6 @@
 ---
-title: Using transactions
-description: Tips for implementing transactions in Azure SQL Data Warehouse for developing solutions.
+title: Use transactions in Synapse SQL pool
+description: This article includes tips for implementing transactions and developing solutions in Synapse SQL pool.
 services: synapse-analytics
 author: XiaoyuMSFT 
 manager: craigg
@@ -13,19 +13,23 @@ ms.reviewer: igorstan
 ms.custom: seo-lt-2019
 ---
 
-# Using transactions in SQL Data Warehouse
-Tips for implementing transactions in Azure SQL Data Warehouse for developing solutions.
+# Use transactions in Synapse SQL pool
+This article includes tips for implementing transactions and developing solutions in SQL pool.
 
 ## What to expect
-As you would expect, SQL Data Warehouse supports transactions as part of the data warehouse workload. However, to ensure the performance of SQL Data Warehouse is maintained at scale some features are limited when compared to SQL Server. This article highlights the differences and lists the others. 
+As you would expect, SQL pool supports transactions as part of the data warehouse workload. However, to ensure SQL pool is maintained at scale, some features are limited when compared to SQL Server. This article highlights the differences. 
 
 ## Transaction isolation levels
-SQL Data Warehouse implements ACID transactions. The isolation level of the transactional support is default to READ UNCOMMITTED.  You can change it to READ COMMITTED SNAPSHOT ISOLATION by turning ON the READ_COMMITTED_SNAPSHOT database option for a user database when connected to the master database.  Once enabled, all transactions in this database are executed under READ COMMITTED SNAPSHOT ISOLATION and setting READ UNCOMMITTED on session level will not be honored. Check [ALTER DATABASE SET options (Transact-SQL)](https://docs.microsoft.com/sql/t-sql/statements/alter-database-transact-sql-set-options?view=azure-sqldw-latest) for details.
+SQL pool implements ACID transactions. The isolation level of the transactional support is default to READ UNCOMMITTED.  You can change it to READ COMMITTED SNAPSHOT ISOLATION by turning ON the READ_COMMITTED_SNAPSHOT database option for a user database when connected to the master database.  
+
+Once enabled, all transactions in this database are executed under READ COMMITTED SNAPSHOT ISOLATION and setting READ UNCOMMITTED on session level will not be honored. Check [ALTER DATABASE SET options (Transact-SQL)](https://docs.microsoft.com/sql/t-sql/statements/alter-database-transact-sql-set-options?view=azure-sqldw-latest) for details.
 
 ## Transaction size
-A single data modification transaction is limited in size. The limit is applied per distribution. Therefore, the total allocation can be calculated by multiplying the limit by the distribution count. To approximate the maximum number of rows in the transaction divide the distribution cap by the total size of each row. For variable length columns, consider taking an average column length rather than using the maximum size.
+A single data modification transaction is limited in size. The limit is applied per distribution. Therefore, the total allocation can be calculated by multiplying the limit by the distribution count. 
+
+To approximate the maximum number of rows in the transaction divide the distribution cap by the total size of each row. For variable length columns, consider taking an average column length rather than using the maximum size.
 
-In the table below the following assumptions have been made:
+In the following table, two assumptions have been made:
 
 * An even distribution of data has occurred 
 * The average row length is 250 bytes
@@ -79,14 +83,17 @@ To optimize and minimize the amount of data written to the log, please refer to
 > 
 
 ## Transaction state
-SQL Data Warehouse uses the XACT_STATE() function to report a failed transaction using the value -2. This value means the transaction has failed and is marked for rollback only.
+SQL pool uses the XACT_STATE() function to report a failed transaction using the value -2. This value means the transaction has failed and is marked for rollback only.
 
 > [!NOTE]
-> The use of -2 by the XACT_STATE function to denote a failed transaction represents different behavior to SQL Server. SQL Server uses the value -1 to represent an uncommittable transaction. SQL Server can tolerate some errors inside a transaction without it having to be marked as uncommittable. For example `SELECT 1/0` would cause an error but not force a transaction into an uncommittable state. SQL Server also permits reads in the uncommittable transaction. However, SQL Data Warehouse does not let you do this. If an error occurs inside a SQL Data Warehouse transaction it will automatically enter the -2 state and you will not be able to make any further select statements until the statement has been rolled back. It is therefore important to check that your application code to see if it uses  XACT_STATE() as you may need to make code modifications.
-> 
-> 
+> The use of -2 by the XACT_STATE function to denote a failed transaction represents different behavior to SQL Server. SQL Server uses the value -1 to represent an uncommittable transaction. SQL Server can tolerate some errors inside a transaction without it having to be marked as uncommittable. For example, `SELECT 1/0` would cause an error but not force a transaction into an uncommittable state. 
 
-For example, in SQL Server you might see a transaction that looks like the following:
+SQL Server also permits reads in the uncommittable transaction. However, SQL pool does not let you do this. If an error occurs inside a SQL pool transaction, it will automatically enter the -2 state and you will not be able to make any further select statements until the statement has been rolled back. 
+
+As such, it's important to check that your application code to see if it uses  XACT_STATE() as you may need to make code modifications.
+
+
+For example, in SQL Server, you might see a transaction that looks like the following:
 
 ```sql
 SET NOCOUNT ON;
@@ -127,11 +134,11 @@ SELECT @xact_state AS TransactionState;
 The preceding code gives the following error message:
 
 Msg 111233, Level 16, State 1, Line 1
-111233; The current transaction has aborted, and any pending changes have been rolled back. Cause: A transaction in a rollback-only state was not explicitly rolled back before a DDL, DML, or SELECT statement.
+111233; The current transaction has aborted, and any pending changes have been rolled back. The cause of this issue is that a transaction in a rollback-only state not being explicitly rolled back before a DDL, DML, or SELECT statement.
 
 You won't get the output of the ERROR_* functions.
 
-In SQL Data Warehouse the code needs to be slightly altered:
+In SQL pool the code needs to be slightly altered:
 
 ```sql
 SET NOCOUNT ON;
@@ -173,17 +180,19 @@ The expected behavior is now observed. The error in the transaction is managed a
 All that has changed is that the ROLLBACK of the transaction had to happen before the read of the error information in the CATCH block.
 
 ## Error_Line() function
-It is also worth noting that SQL Data Warehouse does not implement or support the ERROR_LINE() function. If you have this in your code, you need to remove it to be compliant with SQL Data Warehouse. Use query labels in your code instead to implement equivalent functionality. For more details, see the [LABEL](sql-data-warehouse-develop-label.md) article.
+It is also worth noting that SQL pool does not implement or support the ERROR_LINE() function. If you have this in your code, you need to remove it to be compliant with SQL pool. 
+
+Use query labels in your code instead to implement equivalent functionality. For more details, see the [LABEL](sql-data-warehouse-develop-label.md) article.
 
 ## Using THROW and RAISERROR
-THROW is the more modern implementation for raising exceptions in SQL Data Warehouse but RAISERROR is also supported. There are a few differences that are worth paying attention to however.
+THROW is the more modern implementation for raising exceptions in SQL pool but RAISERROR is also supported. There are a few differences that are worth paying attention to however.
 
 * User-defined error messages numbers cannot be in the 100,000 - 150,000 range for THROW
 * RAISERROR error messages are fixed at 50,000
 * Use of sys.messages is not supported
 
 ## Limitations
-SQL Data Warehouse does have a few other restrictions that relate to transactions.
+SQL pool does have a few other restrictions that relate to transactions.
 
 They are as follows:
 
@@ -195,5 +204,5 @@ They are as follows:
 * No support for DDL such as CREATE TABLE inside a user-defined transaction
 
 ## Next steps
-To learn more about optimizing transactions, see [Transactions best practices](sql-data-warehouse-develop-best-practices-transactions.md). To learn about other SQL Data Warehouse best practices, see [SQL Data Warehouse best practices](sql-data-warehouse-best-practices.md).
+To learn more about optimizing transactions, see [Transactions best practices](sql-data-warehouse-develop-best-practices-transactions.md). To learn about other SQL pool best practices, see [SQL pool best practices](sql-data-warehouse-best-practices.md).
 

articles/synapse-analytics/sql-data-warehouse/sql-data-warehouse-develop-user-defined-schemas.md

@@ -1,6 +1,6 @@
 ---
 title: Using user-defined schemas 
-description: Tips for using T-SQL user-defined schemas in Azure SQL Data Warehouse for developing solutions.
+description: Tips for using T-SQL user-defined schemas to develop solutions in Synapse SQL pool.
 services: synapse-analytics
 author: XiaoyuMSFT 
 manager: craigg
@@ -13,42 +13,44 @@ ms.reviewer: igorstan
 ms.custom: seo-lt-2019
 ---
 
-# Using user-defined schemas in SQL Data Warehouse
-Tips for using T-SQL user-defined schemas in Azure SQL Data Warehouse for developing solutions.
+# User-defined schemas in Synapse SQL pool
+This article focuses on providing several tips for using T-SQL user-defined schemas to develop solutions in Synapse SQL pool.
 
 ## Schemas for application boundaries
 
-Traditional data warehouses often use separate databases to create application boundaries based on either workload, domain or security. For example, a traditional SQL Server data warehouse might include a staging database, a data warehouse database, and some data mart databases. In this topology each database operates as a workload and security boundary in the architecture.
+Traditional data warehouses often use separate databases to create application boundaries based on either workload, domain or security. 
 
-By contrast, SQL Data Warehouse runs the entire data warehouse workload within one database. Cross database joins are not permitted. Therefore SQL Data Warehouse expects all tables used by the warehouse to be stored within the one database.
+As an example, a traditional SQL Server data warehouse might include a staging database, a data warehouse database, and some data mart databases. In this topology, each database operates as a workload and security boundary in the architecture.
+
+By contrast, SQL pool runs the entire data warehouse workload within one database. Cross database joins aren't permitted. SQL pool expects all tables used by the warehouse to be stored within the one database.
 
 > [!NOTE]
-> SQL Data Warehouse does not support cross database queries of any kind. Consequently, data warehouse implementations that leverage this pattern will need to be revised.
+> SQL pool does not support cross database queries of any kind. Consequently, data warehouse implementations that leverage this pattern will need to be revised.
 > 
 > 
 
 ## Recommendations
-These are recommendations for consolidating workloads, security, domain and functional boundaries by using user defined schemas
+What follows are recommendations for consolidating workloads, security, domain, and functional boundaries by using user-defined schemas:
 
-1. Use one SQL Data Warehouse database to run your entire data warehouse workload
-2. Consolidate your existing data warehouse environment to use one SQL Data Warehouse database
-3. Leverage **user-defined schemas** to provide the boundary previously implemented using databases.
+- Use one SQL pool database to run your entire data warehouse workload.
+- Consolidate your existing data warehouse environment to use one SQL pool database.
+- Leverage **user-defined schemas** to provide the boundary previously implemented using databases.
 
-If user-defined schemas have not been used previously then you have a clean slate. Simply use the old database name as the basis for your user-defined schemas in the SQL Data Warehouse database.
+If user-defined schemas have not been used previously, then you have a clean slate. Use the old database name as the basis for your user-defined schemas in the SQL pool database.
 
-If schemas have already been used then you have a few options:
+If schemas have already been used, then you have a few options:
 
-1. Remove the legacy schema names and start fresh
-2. Retain the legacy schema names by pre-pending the legacy schema name to the table name
-3. Retain the legacy schema names by implementing views over the table in an extra schema to re-create the old schema structure.
+- Remove the legacy schema names and start fresh.
+- Retain the legacy schema names by pre-pending the legacy schema name to the table name.
+- Retain the legacy schema names by implementing views over the table in an extra schema to re-create the old schema structure.
 
 > [!NOTE]
-> On first inspection option 3 may seem like the most appealing option. However, the devil is in the detail. Views are read only in SQL Data Warehouse. Any data or table modification would need to be performed against the base table. Option 3 also introduces a layer of views into your system. You might want to give this some additional thought if you are using views in your architecture already.
+> On first inspection option 3 may seem like the most appealing option. However, the devil is in the detail. Views are read only in SQL pool. Any data or table modification would need to be performed against the base table. Option 3 also introduces a layer of views into your system. You might want to give this some additional thought if you are using views in your architecture already.
 > 
 > 
 
 ### Examples:
-Implement user-defined schemas based on database names
+Implement user-defined schemas based on database names:
 
 ```sql
 CREATE SCHEMA [stg]; -- stg previously database name for staging database
@@ -66,7 +68,7 @@ CREATE TABLE [edw].[customer] -- create data warehouse tables in the edw schema
 );
 ```
 
-Retain legacy schema names by pre-pending them to the table name. Use schemas for the workload boundary.
+Keep legacy schema names by pre-pending them to the table name. Use schemas for the workload boundary:
 
 ```sql
 CREATE SCHEMA [stg]; -- stg defines the staging boundary
@@ -84,7 +86,7 @@ CREATE TABLE [edw].[dim_customer] --pre-pend the old schema name to the table an
 );
 ```
 
-Retain legacy schema names using views
+Keep legacy schema names using views:
 
 ```sql
 CREATE SCHEMA [stg]; -- stg defines the staging boundary
@@ -112,7 +114,7 @@ FROM    [edw].customer
 ```
 
 > [!NOTE]
-> Any change in schema strategy needs a review of the security model for the database. In many cases you might be able to simplify the security model by assigning permissions at the schema level. If more granular permissions are required then you can use database roles.
+> Any change in schema strategy needs a review of the security model for the database. In many cases, you might be able to simplify the security model by assigning permissions at the schema level. If more granular permissions are required, then you can use database roles.
 > 
 > 
 

articles/synapse-analytics/sql-data-warehouse/sql-data-warehouse-develop-variable-assignment.md

@@ -1,6 +1,6 @@
 ---
 title: Assign variables
-description: Tips for assigning T-SQL variables in Azure SQL Data Warehouse for developing solutions.
+description: In this article, you'll find essential tips for assigning T-SQL variables in SQL pool.
 services: synapse-analytics
 author: XiaoyuMSFT 
 manager: craigg
@@ -13,36 +13,36 @@ ms.reviewer: igorstan
 ms.custom: seo-lt-2019
 ---
 
-# Assigning variables in Azure SQL Data Warehouse
+# Assign variables in Synapse SQL pool
 
-Tips for assigning T-SQL variables in Azure SQL Data Warehouse for developing solutions.
+In this article, you'll find essential tips for assigning T-SQL variables in SQL pool.
 
-## Setting variables with DECLARE
+## Set variables with DECLARE
 
-Variables in SQL Data Warehouse are set using the `DECLARE` statement or the `SET` statement. Initializing variables with DECLARE is one of the most flexible ways to set a variable value in SQL Data Warehouse.
+Variables in SQL pool are set using the `DECLARE` statement or the `SET` statement. Initializing variables with DECLARE is one of the most flexible ways to set a variable value in SQL pool.
 
 ```sql
 DECLARE @v  int = 0
 ;
 ```
 
-You can also use DECLARE to set more than one variable at a time. You cannot use SELECT or UPDATE to do the following:
+You can also use DECLARE to set more than one variable at a time. You can't use SELECT or UPDATE to do the following:
 
 ```sql
 DECLARE @v  INT = (SELECT TOP 1 c_customer_sk FROM Customer where c_last_name = 'Smith')
 ,       @v1 INT = (SELECT TOP 1 c_customer_sk FROM Customer where c_last_name = 'Jones')
 ;
 ```
 
-You cannot initialize and use a variable in the same DECLARE statement. To illustrate the point, the following example is **not** allowed since @p1 is both initialized and used in the same DECLARE statement. The following example gives an error.
+You can't initialize and use a variable in the same DECLARE statement. To illustrate the point, the following example is **not** allowed since @p1 is both initialized and used in the same DECLARE statement. As such, the following example gives an error:
 
 ```sql
 DECLARE @p1 int = 0
 ,       @p2 int = (SELECT COUNT (*) FROM sys.types where is_user_defined = @p1 )
 ;
 ```
 
-## Setting values with SET
+## Set values with SET
 
 SET is a common method for setting a single variable.
 
@@ -59,7 +59,7 @@ You can only set one variable at a time with SET. However, compound operators ar
 
 ## Limitations
 
-You cannot use UPDATE for variable assignment.
+You can't use UPDATE for variable assignment.
 
 ## Next steps