minor updates as acrolinx

Author: sevend2

support/sql/analysis-services/cannot-connect-named-instance.md

@@ -27,13 +27,13 @@ You might not able to connect to a named instance of Analysis Services that is i
 ## Cause
 
 The problem occurs when you start the named instance of SQL Server Analysis services (SSAS) using either SQL Server Configuration Manager or the Services applet in the Control panel.
-When you start an SSAS instance on a failover cluster using a tool other than Failover Cluster Management (Cluster administrator on older Operating Systems), that SSAS instance will run as a stand-alone instance and will listen on a non-default port resulting in connection failures from various applications.
+When you start an SSAS instance on a failover cluster using a tool other than Failover Cluster Management (Cluster administrator on older Operating Systems), that SSAS instance will run as a stand-alone instance and will listen on a nondefault port resulting in connection failures from various applications.
 
 ## Resolution
 
 Stop and restart the SQL Server Analysis services using the Failover Cluster Management tool.
 
 ## More information
 
-An SSAS instance started on a cluster (default or named instance) will start listening on all IP addresses of the cluster group using the default port of 2383. The server setting `<Port>` property does not change the port number of SSAS service on a cluster.
+An SSAS instance started on a cluster (default or named instance) will start listening on all IP addresses of the cluster group using the default port of 2383. The server setting `<Port>` property doesn't change the port number of SSAS service on a cluster.
 

support/sql/analysis-services/writeback-performance-issue-cell-security-enable.md

@@ -14,14 +14,14 @@ _Original KB number:_   2747616
 
 ## Symptoms
 
-Assume that you are running Microsoft SQL Server Analysis Services (SSAS) under a role for which cell security is enabled. When you try to execute an UPDATE CUBE Multidimensional Expressions (MDX) statement, the statement execution may take longer to execute than for a role for which cell security is not enabled.
+Assume that you're running Microsoft SQL Server Analysis Services (SSAS) under a role for which cell security is enabled. When you try to execute an UPDATE CUBE Multidimensional Expressions (MDX) statement, the statement execution may take longer to execute than for a role for which cell security isn't enabled.
 
 ## Cause
 
 This behavior is by design. When cell security is enabled, the Analysis Services engine executes the queries in cell-by-cell mode. If the writeback operation performs allocation at a high level, the space of leaf level cells will be large.
 
 > [!NOTE]
-> The space is not the number of rows in the fact table. The space is the full cross join space of all dimension granularity attributes. It takes a long time to enumerate those cells one-by-one in order to check the cell security.
+> The space isn't the number of rows in the fact table. The space is the full cross join space of all dimension granularity attributes. It takes a long time to enumerate those cells one-by-one in order to check the cell security.
 
 ## Workaround
 
@@ -36,7 +36,7 @@ To work around this issue, use one of the following methods.
 
 - Method 2  
 
-    Perform the writeback operation at the lowest granularity level of a certain member. You cannot allocate for many detailed granularity members.
+    Perform the writeback operation at the lowest granularity level of a certain member. You can't allocate for many detailed granularity members.
 
     > [!NOTE]
     > You may have to create dummy members in dimension tables that are marked as adjustment members in each dimension, to support the writeback operation.

support/sql/analytics-platform-system/detect-data-skew-distribution-key-values.md

@@ -30,9 +30,9 @@ order by count(distribtuion_key) desc
 ```
 
 > [!NOTE]
-> The `having` clause is commented out. However, if you want to perform a quick check of whether there is significant skew, this clause may tell you. You may have to adjust the having value to something that makes sense for your result set. For example, if all values have 5,000 records, we recommend that you set this value to 7,500 or 10,000 to indicate an issue.
+> The `having` clause is commented out. However, if you want to perform a quick check of whether there's significant skew, this clause may tell you. You may have to adjust the having value to something that makes sense for your result set. For example, if all values have 5,000 records, we recommend that you set this value to 7,500 or 10,000 to indicate an issue.
 
-The question of when skew becomes a problem does not have a deterministic answer. Skew becomes a problem when performance of skewed distributions becomes noticeable and the application cannot tolerate the situation. The rule of thumb is that the appliance can tolerate a skew of 10 to 20 percent across all the tables. Within this threshold, the skewed distributions should even out under concurrency. Above this threshold, you may start to see some long-running distributions when the data is processed. Some implementations may be able to tolerate greater skew, and some implementations may be unable to tolerate this much. Testing is required to determine the actual threshold for your implementation.
+The question of when skew becomes a problem doesn't have a deterministic answer. Skew becomes a problem when performance of skewed distributions becomes noticeable and the application can't tolerate the situation. The rule of thumb is that the appliance can tolerate a skew of 10 to 20 percent across all the tables. Within this threshold, the skewed distributions should even out under concurrency. Above this threshold, you may start to see some long-running distributions when the data is processed. Some implementations may be able to tolerate greater skew, and some implementations may be unable to tolerate this much. Testing is required to determine the actual threshold for your implementation.
 
 ## More information
 

support/sql/data-quality-services/error-you-run-dqs-cleansing-transformation.md

@@ -17,7 +17,7 @@ _Original KB number:_   2715968
 Consider the following scenario:
 
 - You use the Data Quality Services (DQS) Cleansing transformation in a SQL Server-Integrated Service (SSIS) Data Flow to cleanse your data in Microsoft SQL Server.
-- You set the "Configure error output" setting of the DQS Cleansing transformation to "Redirect row." However, you do not specify a location to save the error output.
+- You set the "Configure error output" setting of the DQS Cleansing transformation to "Redirect row." However, you don't specify a location to save the error output.
 - You execute the SSIS package.
 
 In this scenario, the following error message is logged in the SSIS log:
@@ -30,19 +30,19 @@ at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostPreExecute(IDTSMana
 
 ## Cause
 
-This problem occurs because a destination is not set for the error output that is generated for rows that do not meet the DQS domain criteria and rules.
+This problem occurs because a destination isn't set for the error output that is generated for rows that don't meet the DQS domain criteria and rules.
 
 ## Resolution
 
 To resolve this issue, use one of the following methods:
 
 - Method 1
 
-  If you do not want to redirect error rows, follow these steps to resolve the issue:
+  If you don't want to redirect error rows, follow these steps to resolve the issue:
 
   1. Open the DQS Component in the DQS Cleansing Transformation Editor.  
   1. Select Fail Component in the Configure error output drop-down list at the bottom of the DQS Cleansing Transformation Editor.
 
 - Method 2
 
-  If you have to redirect your error rows, then you must make sure that you have a destination location for the errors to be redirected to.
+  If you have to redirect your error rows, you must make sure that you have a destination location for the errors to be redirected to.

support/sql/master-data-services/mds-validate-version-command-fails.md

@@ -20,13 +20,13 @@ Consider the following scenario:
 
 - Later, you browse to the MDS website and then follow these steps:
 
-    1. You click the **Manage Versions** page.
+  1. Select the **Manage Versions** page.
 
-    1. You click the **Validate Version** command on the top toolbar.
+  1. Select the **Validate Version** command on the top toolbar.
 
-    1. You select the **Validate** check box for **Model**.
+  1. Select the **Validate** check box for **Model**.
 
-    1. You confirm the **Are you sure that you want to validate this version?** prompt and then click **OK**.
+  1. You confirm the **Are you sure that you want to validate this version?** prompt and then select **OK**.
 
 In this scenario, you receive the following error message in the browser window:
 
@@ -54,21 +54,21 @@ System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boo
 
 ## Cause
 
-This problem occurs because new accounts are not granted the `VIEW SERVER STATE` permission.
+This problem occurs because new accounts aren't granted the `VIEW SERVER STATE` permission.
 
 When you use the Master Data Services Configuration Manager utility to create an MDS website, the tool prompts you for the application pool user account credentials for the application pool identity.
 
 Next, after the MDS server and database are selected, the tool grants permissions to the account. The specified application pool credential account is granted several permissions in the specified MDS database and is added to the `MDS_ServiceAccounts` local users group and to the `mds_exec` database role within the specified MDS database catalog.
 
-However, the `VIEW SERVER STATE` permission is not granted to the master database. Sometimes, Windows accounts may have that permission in SQL Server. However, by default, new accounts are not granted that permission.
+However, the `VIEW SERVER STATE` permission isn't granted to the master database. Sometimes, Windows accounts may have that permission in SQL Server. However, by default, new accounts aren't granted that permission.
 
 The `VIEW SERVER STATE` permission is useful to query the service broker by using the `sys.dm_broker_activated_tasks` dynamic management view (DMV) to check the progress of queued background activity.
 
-The MDS web application internally runs the exec `mdm.udpValidationIsRunning` stored procedure to check the validation progress. However, the application pool credential that is running the query does not have permissions to the DMV and receives the following error message:
+The MDS web application internally runs the exec `mdm.udpValidationIsRunning` stored procedure to check the validation progress. However, the application pool credential that is running the query doesn't have permissions to the DMV and receives the following error message:
 
 > The user does not have permission to perform this action.
 
-The following statement inside the procedure fails, and the webpage is not rendered:
+The following statement inside the procedure fails, and the webpage isn't rendered:
 
 ```sql
 IF EXISTS (SELECT 1 FROM sys.dm_broker_activated_tasks
@@ -98,21 +98,21 @@ To determine whether this problem is related to the `VIEW SERVER STATE` permissi
 
 > The user does not have permission to perform this action.
 
-Then, check the account for effective permissions, and add the permissions if it is necessary. To do this, follow these steps:
+Then, check the account for effective permissions, and add the permissions if it's necessary. To do this, follow these steps:
 
 1. Open Management Studio, and then connect to the SQL Server database engine that is hosting the MDS catalog.
 
 1. In the **Object Explorer** pane, expand the **Security** folder.
 
 1. Locate the account that is used to run the IIS MDS application pool.
 
-1. Right-click the account, and then click **Properties**.
+1. Right-click the account, and then select **Properties**.
 
-1. Click the **Securables** page. In the bottom pane, click the **Effective** tab.
+1. Select the **Securables** page. In the bottom pane, select the **Effective** tab.
 
     - If the effective permission `VIEW SERVER STATE` is listed, this is likely not the problem.
 
-    - If the permission is not listed, return to the **Explicit** tab on the **Login Properties** dialog box, and then click to select the **View Server State Permissions** check box to grant permissions to the account.
+    - If the permission isn't listed, return to the **Explicit** tab on the **Login Properties** dialog box, and then select the **View Server State Permissions** check box to grant permissions to the account.
 
 ## References
 

support/sql/ssms/exception-you-execute-query.md

@@ -31,16 +31,16 @@ To work around this issue, try one of the following methods.
 Configure the query window to output the query results as text. A text output uses less memory than the grid, and it may be sufficient to display the query results. To make this change, follow these steps:
 
 1. Right-click the query window.
-2. Click **Results to**.
-3. Click **Results to Text**.
+2. Select **Results to**.
+3. Select **Results to Text**.
 
 ## Method 2: Output the results to a file
 
 Configure the query window to output the query results to a file. A file output uses a minimal amount of memory. This reserves more memory for storing the results set. To make this change, follow these steps:
 
 1. Right-click the query window.
-2. Click **Results to**.
-3. Click **Results To File**.
+2. Select **Results to**.
+3. Select **Results To File**.
 4. Run the query, and then select the location in which to save the results file.
 
 ## Method 3: Use sqlcmd