updated TOC and impoved acrolinx

Author: markingmyname

.openpublishing.redirection.json

@@ -41472,7 +41472,7 @@
     },
     {
       "source_path": "docs/ssdt/check-for-updates-dialog-box.md",
-      "redirect_url": "/sql/ssdt/sql-server-data-tools.md",
+      "redirect_url": "/sql/ssdt/sql-server-data-tools",
       "redirect_document_id": false
     },
     {

docs/ssdt/how-to-change-target-platform-and-publish-a-database-project.md

@@ -16,11 +16,11 @@ f1_keywords:
 
 You can change the target SQL Server version for your SQL Server Data Tools (SSDT) database project to any supported instance of SQL Server (SQL Server 2005, 2008, 2008 R2, Microsoft SQL Server 2012, or SQL Azure). By doing so, you can centralize your database development in one project, but publish it to multiple SQL Server instances as the need arises.  
 
-SSDT also makes this task simple by being aware of your target platform and automatically detecting any error in your code (for example., when you are using unsupported features for a project that is going to be published to SQL Azure).  
+SSDT also makes this task simple by being aware of your target platform and automatically detecting any error in your code (for example, when you're using unsupported features for a project that is going to be published to SQL Azure).  
 
 ### To change a project's target platform  
 
-1.  Right-click your project in **Solution Explorer** and select **Properties**. Click the **Project Settings** tab on the left to access the **Project Settings** property page.  
+1.  Right-click your project in **Solution Explorer** and select **Properties**. Select the **Project Settings** tab on the left to access the **Project Settings** property page.  
 
 2.  The **Target platform** dropdown list in this page contains all the supported SQL Server platforms that a database project can be published to. For this procedure, select **SQL Azure**.  
 
@@ -30,30 +30,30 @@ SSDT also makes this task simple by being aware of your target platform and auto
 
 2.  Append `ON [PRIMARY]` to the end of the `CREATE TABLE` statement.  
 
-3.  Notice that the following error shows up in the **Error List** pane:  SQL70015: 'Filegroup reference and partitioning scheme' is not supported in SQL Azure..  
+3.  Notice that the following error shows up in the **Error List** pane:  SQL70015: 'Filegroup reference and partitioning scheme' isn't supported in SQL Azure.  
 
-    SSDT automatically validates your script based on the target platform. In this case, since filegroup is not supported in SQL Azure, SSDT returns an error. For a list of non-supported Transact-SQL statements in SQL Azure, see [Partially Supported Transact-SQL Statements (Microsoft Azure SQL Database)](/previous-versions/azure/ee336267(v=azure.100)).  
+    SSDT automatically validates your script based on the target platform. In this case, since filegroup isn't supported in SQL Azure, SSDT returns an error. For a list of nonsupported Transact-SQL statements in SQL Azure, see [Partially Supported Transact-SQL Statements (Microsoft Azure SQL Database)](/previous-versions/azure/ee336267(v=azure.100)).  
 
 4.  Remove the `ON` clause. Notice that the error immediately disappears from the **Error List**.  
 
 ### To publish a database project  
 
 1.  If you have access to a SQL Azure instance, you can skip to the next step. Otherwise, right-click the **TradeDev** project in **Solution Explorer** and select **Properties** to access the **Project Settings** property page. Use the **Target platform** dropdown list to select the SQL Server platform that you want to publish the project to.  
 
-2.  Right-click the **TradeDev** project in **Solution Explorer** and select **Publish**. SSDT will start building your project. If there is no build error, the **Publish Database** dialog box appears.  
+2.  Right-click the **TradeDev** project in **Solution Explorer** and select **Publish**. SSDT will start building your project. If there's no build error, the **Publish Database** dialog box appears.  
 
-3.  In the **Publish Database** dialog box, click **Edit** to edit the Target database connection.  
+3.  In the **Publish Database** dialog box, select **Edit** to edit the Target database connection.  
 
 4.  In the **Connection Properties** dialog box, enter your SQL Server instance name and your credentials for authentication. In **Connect to a database**, enter **NewTrade**. This will attempt to publish your database project to a new database. You can also choose an existing database to publish to. For example, if you choose the existing **TradeDev** database, then all the changes you have been making to the objects (as scripts) in the offline **TradeDev** project will be propagated to the live **TradeDev** database.  
 
-    If you have permission to make any changes to the database you want to publish to, press the **Publish** button. If, however, you do not have write access to a production database, you can click the **Generate Script** button to produce a Transact-SQL publish script, which can then be handed off to a DBA. The DBA can then run the script to update the production server so that its schema is in sync with the database project.  
+    If you have permission to make any changes to the database you want to publish to, press the **Publish** button. If, however, you don't have write access to a production database, you can select the **Generate Script** button to produce a Transact-SQL publish script, which can then be handed off to a DBA. The DBA can then run the script to update the production server so that its schema is in sync with the database project.  
 
 5.  The **Data Tools Operations**  window will show the progress of your publish operations, and notify you of any errors. In this new window, you can also choose to view the deployment preview, the generated script, or the full publish results if desired.  
 
-6.  You can also save the publish settings in a profile, so that you can reuse the same settings for future publish operations. To do so, click the **Save Profile As** button in the **Publish Database** dialog box. In the future, you can click the **Load Profile** button when you want to reload existing settings.  
+6.  You can also save the publish settings in a profile, so that you can reuse the same settings for future publish operations. To do so, select the **Save Profile As** button in the **Publish Database** dialog box. In the future, you can select the **Load Profile** button when you want to reload existing settings.  
 
-7.  Notice the messages in the **Data Tools Operations** window. Click on "View Preview" link to the right of **Creating publish preview...** This will open the deployment preview report. If your project's target platform is not identical to the database server where the project is published to, SSDT will issue a warning in this report.  For example, if your project's target platform is Microsoft SQL Server 2012 and you are attempting to publish the project to a SQL Server 2008 R2 server instance, you will see the following warning in the **Output** window:  
+7.  Notice the messages in the **Data Tools Operations** window. Select on "View Preview" link to the right of **Creating publish preview...** This will open the deployment preview report. If your project's target platform isn't identical to the database server where the project is published to, SSDT will issue a warning in this report.  For example, if your project's target platform is Microsoft SQL Server 2012 and you're attempting to publish the project to a SQL Server 2008 R2 server instance, you'll see the following warning in the **Output** window:  
 
 **A project which specifies Microsoft SQL Server 2012 as the target platform may experience compatibility issues with SQL Server 2008**    If such project contains entities (for example, a Sequence object) that are introduced in Microsoft SQL Server 2012, the publishing operation will fail.  
 
-The deployment will fail if object predicates use **CONTAINS** or **FREETEXT** over a newly created full-text index and transactional scripts are used. If the option to include transactional scripts is enabled during deployment, then procedures and views are defined inside a transaction while a full-text index is defined outside of a transaction at the end of the deploy script. Because of this ordering in the script, procedures or views using CONTAINS or FREETEXT will not be resolved against the full-text index, resulting in a deployment error.  
+The deployment will fail if object predicates use **CONTAINS** or **FREETEXT** over a newly created full-text index and transactional scripts are used. If the option to include transactional scripts is enabled during deployment, then procedures and views are defined inside a transaction while a full-text index is defined outside of a transaction at the end of the deploy script. Because of this ordering in the script, procedures or views using CONTAINS or FREETEXT won't be resolved against the full-text index, resulting in a deployment error.  

docs/ssdt/how-to-clone-an-existing-database.md

@@ -23,23 +23,23 @@ By using these steps, you can easily create a development or test database from
 
 3.  Rename the new database to **TradeDev**.  
 
-4.  Right-click the **Trade** database in **SQL Server Object Explorer**, and select **Schema Compare**. Follow the steps in the [How to: Use Schema Compare to Compare Different Database Definitions](../ssdt/how-to-use-schema-compare-to-compare-different-database-definitions.md) topic, choosing the original **Trade** database as the source and the new **TradeDev** database as the target. This will update **TradeDev** with the schema from **Trade**.  
+4.  Right-click the **Trade** database in **SQL Server Object Explorer**, and select **Schema Compare**. Follow the steps in the [How to: Use Schema Compare to Compare Different Database Definitions](../ssdt/how-to-use-schema-compare-to-compare-different-database-definitions.md) article, choosing the original **Trade** database as the source and the new **TradeDev** database as the target. This updates **TradeDev** with the schema from **Trade**.  
 
 ### To replicate data  
 
-1.  The previous step has duplicated only the schema of the production database to the development database. In this procedure, you will duplicate production data to the development database.  
+1.  The previous step has duplicated only the schema of the production database to the development database. In this procedure, you duplicate production data to the development database.  
 
     Right-click the **Suppliers** table in the **Trade** database and select **View Data**. The Data Editor opens.  
 
-2.  Click the **Script** button next to **Max Rows** in the toolbar.  
+2.  Select the **Script** button next to **Max Rows** in the toolbar.  
 
-3.  When the script window opens, make sure Connected is shown in the status bar below the Transact-SQL script pane. If Disconnected is shown, click the **Connect** button (the leftmost one in the toolbar) and enter your server information and credentials.  
+3.  When the script window opens, make sure Connected is shown in the status bar below the Transact-SQL script pane. If Disconnected is shown, select the **Connect** button (the leftmost one in the toolbar) and enter your server information and credentials.  
 
 4.  In the **Database** dropdown menu next to the **Connect**/**Disconnect** buttons, select **TradeDev**. This is similar to the Transact-SQL`USE` statement, and will ensure that the script in the code editor will be executed against the **TradeDev** database.  
 
-5.  Click the **Execute Query** button to execute the `INSERT` statements. This will insert all the rows from the `Suppliers` table of the `Trade` database to the `Suppliers` table in the `TradeDev` database.  
+5.  Select the **Execute Query** button to execute the `INSERT` statements. This inserts all the rows from the `Suppliers` table of the `Trade` database to the `Suppliers` table in the `TradeDev` database.  
 
-6.  Repeat the above steps for all the tables in the `Trade`database, so that they are replicated to the `TradeDev`database.  
+6.  Repeat the above steps for all the tables in the `Trade`database, so that they're replicated to the `TradeDev`database.  
 
 7.  Use the Data Editor to verify that all the tables in the new `TradeDev`database have been populated.  
 

docs/ssdt/how-to-create-a-new-database-project.md

@@ -26,11 +26,11 @@ The following two procedures essentially achieve the same goal by creating a new
 
 2.  In the **Import Database** dialog box, notice that the **Source database connection** settings have been predefined by the database you have selected in **SQL Server Object Explorer**. In the **Target project** setting, change the name of the project to **TradeDev**.  
 
-3.  In the **Import Settings** section, notice the options for importing specific objects and settings, and creating folders for each schema and/or object type. For an organized hierarchy of all your database objects, accept all default settings and click **Start**.  
+3.  In the **Import Settings** section, notice the options for importing specific objects and settings, and creating folders for each schema and/or object type. For an organized hierarchy of all your database objects, accept all default settings and select **Start**.  
 
-4.  The **Import Database** dialog shows a progress bar and displays a list of objects SSDT is importing. When the import operation has completed, click **Finish** to exit the final screen.  
+4.  The **Import Database** dialog shows a progress bar and displays a list of objects SSDT is importing. When the import operation has completed, select **Finish** to exit the final screen.  
 
-5.  Examine the hierarchy in the **Solution Explorer**. Expand the **dbo** folder and you will find separate **Functions**, **Tables** and **Views** folders. Notice that the tables and function are grouped under their schema folders.  
+5.  Examine the hierarchy in the **Solution Explorer**. Expand the **dbo** folder and you'll find separate **Functions**, **Tables, and **Views** folders. Notice that the tables and function are grouped under their schema folders.  
 
 6.  Double-click **Products.sql** under **Tables**. The **Table Designer** opens, showing the visual interpretation of the table in the Columns Grid, and the script definition of the table in the Script Pane. This is identical to what we see in the [Manage Tables, Relationships, and Fix Errors](../ssdt/manage-tables-relationships-and-fix-errors.md)section.  
 
@@ -42,19 +42,19 @@ The following two procedures essentially achieve the same goal by creating a new
 
 ### To create a new project and import existing database schema  
 
-1.  Click **File**, **New**, then **Project**. In the **New Project** dialog box, select **SQL Server** in the left pane. Notice that there is only one type of database project: the **SQL Server Database Project**. There is no platform-specific project as in previous versions of Visual Studio. You will be able to set your target platform in the **Project Settings** dialog box after the project has been created. Such task will be covered in the [How to: Change Target Platform and Publish a Database Project](../ssdt/how-to-change-target-platform-and-publish-a-database-project.md) topic.  
+1.  Select **File**, **New**, then **Project**. In the **New Project** dialog box, select **SQL Server** in the left pane. Notice that there's only one type of database project: the **SQL Server Database Project**. There's no platform-specific project as in previous versions of Visual Studio. You'll be able to set your target platform in the **Project Settings** dialog box after the project has been created. Such task is covered in the [How to: Change Target Platform and Publish a Database Project](../ssdt/how-to-change-target-platform-and-publish-a-database-project.md) article.  
 
-2.  Change the name of the project to **TradeDev** and click **OK** to create the new project.  
+2.  Change the name of the project to **TradeDev** and select **OK** to create the new project.  
 
 3.  Right-click the newly created **TradeDev** project in **Solution Explorer**, select **Import**, then **Database**.  
 
-    The **Import Database** dialog box opens. In the **Source database connection** section, click **Choose a database** and select **TradeDev**. If **TradeDev** is absent from the dropdown list, use the **New Connection** button to edit the Connection Properties.  
+    The **Import Database** dialog box opens. In the **Source database connection** section, select **Choose a database** and select **TradeDev**. If **TradeDev** is absent from the dropdown list, use the **New Connection** button to edit the Connection Properties.  
 
-4.  In the **Import Settings** section, notice the options for importing specific objects and settings, and creating folders for each schema and/or object type. For an organized hierarchy of all your database objects, accept all default settings and click **Start**.  
+4.  In the **Import Settings** section, notice the options for importing specific objects and settings, and creating folders for each schema and/or object type. For an organized hierarchy of all your database objects, accept all default settings and select **Start**.  
 
-5.  The **Import Database** dialog shows a progress bar and displays a list of objects SSDT is importing. When the import operation has completed, click **Finish** to exit the final screen.  
+5.  The **Import Database** dialog shows a progress bar and displays a list of objects SSDT is importing. When the import operation has completed, select **Finish** to exit the final screen.  
 
-6.  Examine the hierarchy in the **Solution Explorer**. Expand the **dbo** folder and you will find separate **Functions**, **Tables** and **Views** folders. Notice that the tables and function are grouped under their schema folders.  
+6.  Examine the hierarchy in the **Solution Explorer**. Expand the **dbo** folder and you'll find separate **Functions**, **Tables, and **Views** folders. Notice that the tables and function are grouped under their schema folders.  
 
 7.  Double-click **Products.sql** under **Tables**. The **Table Designer** opens, showing the visual interpretation of the table in the Columns Grid, and the script definition of the table in the Script Pane. This is identical to what we see in the [Manage Tables, Relationships, and Fix Errors](../ssdt/manage-tables-relationships-and-fix-errors.md)section.