Fix typos and grammar.

Author: GitHubPang

entity-framework/core/change-tracking/change-detection.md

@@ -179,7 +179,7 @@ The performance of detecting changes is not a bottleneck for most applications.
 As we know from the previous section, both <xref:Microsoft.EntityFrameworkCore.ChangeTracking.ChangeTracker.Entries%60%601?displayProperty=nameWithType> and <xref:Microsoft.EntityFrameworkCore.DbContext.SaveChanges%2A?displayProperty=nameWithType> automatically detect changes. However, after calling Entries, the code does not then make any entity or property state changes. (Setting normal property values on Added entities does not cause any state changes.) The code therefore disables unnecessary automatic change detection when calling down into the base SaveChanges method. The code also makes use of a try/finally block to ensure that the default setting is restored even if SaveChanges fails.
 
 > [!TIP]
-> Do not assume that your code must disable automatic change detection to to perform well. This is only needed when profiling an application tracking many entities indicates that performance of change detection is an issue.
+> Do not assume that your code must disable automatic change detection to perform well. This is only needed when profiling an application tracking many entities indicates that performance of change detection is an issue.
 
 ### Detecting changes and value conversions
 
@@ -234,7 +234,7 @@ Notification entities make use of the <xref:System.ComponentModel.INotifyPropert
 -->
 [!code-csharp[Model](../../../samples/core/ChangeTracking/ChangeDetectionAndNotifications/NotificationEntitiesSamples.cs?name=Model)]
 
-In addition, any collection navigations must implement `INotifyCollectionChanged`; in the example above this satisfied by using an <xref:System.Collections.ObjectModel.ObservableCollection%601> of posts. EF Core also ships with an <xref:Microsoft.EntityFrameworkCore.ChangeTracking.ObservableHashSet%601> implementation that has more efficient lookups at the expense of stable ordering.
+In addition, any collection navigations must implement `INotifyCollectionChanged`; in the example above this is satisfied by using an <xref:System.Collections.ObjectModel.ObservableCollection%601> of posts. EF Core also ships with an <xref:Microsoft.EntityFrameworkCore.ChangeTracking.ObservableHashSet%601> implementation that has more efficient lookups at the expense of stable ordering.
 
 Most of this notification code is typically moved into an unmapped base class. For example:
 
@@ -297,7 +297,7 @@ Instead, EF Core must be configured to use these notification entities. This is
 
 Full notification change tracking requires that both `INotifyPropertyChanging` and `INotifyPropertyChanged` are implemented. This allows original values to be saved just before the property value is changed, avoiding the need for EF Core to create a snapshot when tracking the entity. Entity types that implement only `INotifyPropertyChanged` can also be used with EF Core. In this case, EF still creates a snapshot when tracking an entity to keep track of original values, but then uses the notifications to detect changes immediately, rather than needing DetectChanges to be called.
 
-The different <xref:Microsoft.EntityFrameworkCore.ChangeTrackingStrategy> values are summarized in the the following table.
+The different <xref:Microsoft.EntityFrameworkCore.ChangeTrackingStrategy> values are summarized in the following table.
 
 | ChangeTrackingStrategy                              | Interfaces needed                                      | Needs DetectChanges | Snapshots original values
 |:----------------------------------------------------|--------------------------------------------------------|---------------------|--------------------------

entity-framework/core/change-tracking/explicit-tracking.md

@@ -28,7 +28,7 @@ Entities can be explicitly "attached" to a <xref:Microsoft.EntityFrameworkCore.D
 1. Creating new entities that will be inserted into the database.
 2. Re-attaching disconnected entities that were previously queried by a _different_ DbContext instance.
 
-The first of these will be needed by most applications, and is primary handled by the <xref:Microsoft.EntityFrameworkCore.DbContext.Add%2A?displayProperty=nameWithType> methods.
+The first of these will be needed by most applications, and is primarily handled by the <xref:Microsoft.EntityFrameworkCore.DbContext.Add%2A?displayProperty=nameWithType> methods.
 
 The second is only needed by applications that change entities or their relationships **_while the entities are not being tracked_**. For example, a web application may send entities to the web client where the user makes changes and sends the entities back. These entities are referred to as "disconnected" since they were originally queried from a DbContext, but were then disconnected from that context when sent to the client.
 
@@ -462,7 +462,7 @@ The important point to notice here is that, with generated key values, EF Core i
 
 ### Explicit key values
 
-<xref:Microsoft.EntityFrameworkCore.DbContext.Update%2A?displayProperty=nameWithType>, <xref:Microsoft.EntityFrameworkCore.DbContext.UpdateRange%2A?displayProperty=nameWithType>, and the equivalent methods on <xref:Microsoft.EntityFrameworkCore.DbSet%601> behave exactly as the `Attach` methods described above, except that entities are put into the `Modfied` instead of the `Unchanged` state. For example, to start tracking an existing blog as `Modified`:
+<xref:Microsoft.EntityFrameworkCore.DbContext.Update%2A?displayProperty=nameWithType>, <xref:Microsoft.EntityFrameworkCore.DbContext.UpdateRange%2A?displayProperty=nameWithType>, and the equivalent methods on <xref:Microsoft.EntityFrameworkCore.DbSet%601> behave exactly as the `Attach` methods described above, except that entities are put into the `Modified` instead of the `Unchanged` state. For example, to start tracking an existing blog as `Modified`:
 
 <!--
             context.Update(
@@ -678,7 +678,7 @@ It is unusual to call `Remove` on an entity created with `new`. Further, unlike
 1. Running a query for the entities
 2. Using the `Attach` or `Update` methods on a graph of disconnected entities, as described in the preceding sections.
 
-For example, the code in the previous section is more likely obtain a post from a client and then do something like this:
+For example, the code in the previous section is more likely to obtain a post from a client and then do something like this:
 
 <!--
             context.Attach(post);
@@ -753,7 +753,7 @@ In the preceding examples we were deleting a post, which is a dependent/child en
 This invalid model state can be handled in two ways:
 
 1. Setting FK values to null. This indicates that the dependents/children are no longer related to any principal/parent. This is the default for optional relationships where the foreign key must be nullable. Setting the FK to null is not valid for required relationships, where the foreign key is typically non-nullable.
-2. Deleting the the dependents/children. This is the default for required relationships, and is also valid for optional relationships.
+2. Deleting the dependents/children. This is the default for required relationships, and is also valid for optional relationships.
 
 See [Changing Foreign Keys and Navigations](xref:core/change-tracking/relationship-changes) for detailed information on change tracking and relationships.
 

entity-framework/core/logging-events-diagnostics/interceptors.md

@@ -64,7 +64,7 @@ Low-level database interception is split into the three interfaces shown in the
 
 The base classes <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbCommandInterceptor>, <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbConnectionInterceptor>, and <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbTransactionInterceptor> contain no-op implementations for each method in the corresponding interface. Use the base classes to avoid the need to implement unused interception methods.
 
-The methods on each interceptor type come in pairs, with the first being called before the database operation is started, and the second after the operation has completed. For example. For example, <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbCommandInterceptor.ReaderExecuting%2A?displayProperty=nameWithType> is called before a query is executed, and <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbCommandInterceptor.ReaderExecuted%2A?displayProperty=nameWithType> is called after query has been sent to the database.
+The methods on each interceptor type come in pairs, with the first being called before the database operation is started, and the second after the operation has completed. For example, <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbCommandInterceptor.ReaderExecuting%2A?displayProperty=nameWithType> is called before a query is executed, and <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbCommandInterceptor.ReaderExecuted%2A?displayProperty=nameWithType> is called after query has been sent to the database.
 
 Each pair of methods have both sync and async variations. This allows for asynchronous I/O, such as requesting an access token, to happen as part of intercepting an async database operation.
 
@@ -257,7 +257,7 @@ This interceptor also manipulates the command text. This manipulation is not req
 
 #### After execution
 
-If no cached message is available, or if it has expired, then the code above does not suppress the result. EF Core will therefore execute the query as normal. It will then return to the interceptor's `Executed` method after execution. At this point if the result is not already a cached reader, then the new message ID and string is exacted from the real reader and cached ready for the next use of this query.
+If no cached message is available, or if it has expired, then the code above does not suppress the result. EF Core will therefore execute the query as normal. It will then return to the interceptor's `Executed` method after execution. At this point if the result is not already a cached reader, then the new message ID and string is extracted from the real reader and cached ready for the next use of this query.
 
 <!--
     public override async ValueTask<DbDataReader> ReaderExecutedAsync(

entity-framework/core/logging-events-diagnostics/simple-logging.md

@@ -311,7 +311,7 @@ dbug: 10/6/2020 10:52:45.725 RelationalEventId.TransactionCommitted[20202] (Micr
 
 ### Other content options
 
-Other flags in <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbContextLoggerOptions> can be used to trim down the amount of metadata included in the log. This is can be useful in conjunction with single-line logging. For example:
+Other flags in <xref:Microsoft.EntityFrameworkCore.Diagnostics.DbContextLoggerOptions> can be used to trim down the amount of metadata included in the log. This can be useful in conjunction with single-line logging. For example:
 
 <!--
     protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)

entity-framework/core/what-is-new/ef-core-5.0/whatsnew.md

@@ -219,7 +219,7 @@ These entities can then be queried and updated just like normal entity types wit
 
 In EF Core 3.1, the dependent end of a one-to-one relationship was always considered optional. This was most apparent when using owned entities, as all the owned entity's column were created as nullable in the database, even if they were configured as required in the model.
 
-In EF Core 5.0, a navigation to an owned entity can be configured as as a required dependent. For example:
+In EF Core 5.0, a navigation to an owned entity can be configured as a required dependent. For example:
 
 ```csharp
 protected override void OnModelCreating(ModelBuilder modelBuilder)

entity-framework/ef6/fundamentals/connection-resiliency/commit-failures.md

@@ -42,9 +42,9 @@ When the feature is enabled, EF will automatically add a new table to the databa
 
 Although EF will do a best effort to prune rows from the table when they aren’t needed anymore, the table can grow if the application exits prematurely and for that reason you may need to purge the table manually in some cases.  
 
-## How to handle commit failures with previous Versions
+## How to handle commit failures with previous versions
 
-Before EF 6.1 there was not mechanism to handle commit failures in the EF product. There are several ways to dealing with this situation that can be applied to previous versions of EF6:  
+Before EF 6.1 there was no mechanism to handle commit failures in the EF product. There are several ways to dealing with this situation that can be applied to previous versions of EF6:  
 
 * Option 1 - Do nothing  
 

entity-framework/ef6/fundamentals/connection-resiliency/retry-logic.md

@@ -63,7 +63,7 @@ The SqlAzureExecutionStrategy will retry instantly the first time a transient fa
 
 The execution strategies will only retry a limited number of exceptions that are usually transient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.  
 
-There are some known of limitations when using a retrying execution strategy:  
+There are some known limitations when using a retrying execution strategy:  
 
 ## Streaming queries are not supported  
 

entity-framework/ef6/fundamentals/logging-and-interception.md

@@ -260,7 +260,7 @@ Looking at the methods defined on any of the interceptor interfaces it is appare
 
 ### Result handling  
 
-The DbCommandInterceptionContext\<\> class contains a properties called Result, OriginalResult, Exception, and OriginalException. These properties are set to null/zero for calls to the interception methods that are called before the operation is executed — that is, for the …Executing methods. If the operation is executed and succeeds, then Result and OriginalResult are set to the result of the operation. These values can then be observed in the interception methods that are called after the operation has executed — that is, on the …Executed methods. Likewise, if the operation throws, then the Exception and OriginalException properties will be set.  
+The DbCommandInterceptionContext\<\> class contains properties called Result, OriginalResult, Exception, and OriginalException. These properties are set to null/zero for calls to the interception methods that are called before the operation is executed — that is, for the …Executing methods. If the operation is executed and succeeds, then Result and OriginalResult are set to the result of the operation. These values can then be observed in the interception methods that are called after the operation has executed — that is, on the …Executed methods. Likewise, if the operation throws, then the Exception and OriginalException properties will be set.  
 
 #### Suppressing execution  
 

entity-framework/ef6/fundamentals/providers/index.md

@@ -88,6 +88,6 @@ If the provider is available for previous versions of EF, then we encourage you
 
 ## Can I write a provider myself?
 
-It is certainly possible to create an EF provider yourself although it should not be considered a trivial undertaking. The the link above about the EF6 provider model is a good place to start. You may also find it useful to use the code for the SQL Server and SQL CE provider included in the [EF open source codebase](https://github.com/aspnet/EntityFramework6) as a starting point or for reference.
+It is certainly possible to create an EF provider yourself although it should not be considered a trivial undertaking. The link above about the EF6 provider model is a good place to start. You may also find it useful to use the code for the SQL Server and SQL CE provider included in the [EF open source codebase](https://github.com/aspnet/EntityFramework6) as a starting point or for reference.
 
 Note that starting with EF6 the EF provider is less tightly coupled to the underlying ADO.NET provider. This makes it easier to write an EF provider without needing to write or wrap the ADO.NET classes.

entity-framework/ef6/modeling/code-first/data-types/spatial.md

@@ -141,7 +141,7 @@ To view the database and data, do the following:
 
 1.  In the Visual Studio 2012 main menu, select **View** -> **SQL Server Object Explorer**.
 2.  If LocalDB is not in the list of servers, click the right mouse button on **SQL Server** and select **Add SQL Server**
-    Use the default **Windows Authentication** to connect to the the LocalDB instance
+    Use the default **Windows Authentication** to connect to the LocalDB instance
 3.  Expand the LocalDB node
 4.  Unfold the **Databases** folder to see the new database and browse to the **Universities** table
 5.  To view data, right-click on the table and select **View Data**