summaryrefslogtreecommitdiff
path: root/docs/topics
diff options
context:
space:
mode:
authorEric Boersma <eric.boersma@gmail.com>2013-09-05 18:23:48 -0400
committerTim Graham <timograham@gmail.com>2013-09-05 20:14:58 -0400
commit4d13cc56de46ccfc89e9f1381ba4f194070bbdb7 (patch)
tree5ee6093dd8e9c4d1beb5df46cb16997dad59d6c2 /docs/topics
parent93dd31cadfb5f02352740aac32bc2f6cdf923b48 (diff)
Fixed #21035 -- Changed docs to treat the acronym SQL phonetically.
The documentation and comments now all use 'an' to refer to the word SQL and not 'a'.
Diffstat (limited to 'docs/topics')
-rw-r--r--docs/topics/db/multi-db.txt4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt
index c098aa33e3..51a1028342 100644
--- a/docs/topics/db/multi-db.txt
+++ b/docs/topics/db/multi-db.txt
@@ -442,7 +442,7 @@ Consider the following example::
In statement 1, a new ``Person`` object is saved to the ``first``
database. At this time, ``p`` doesn't have a primary key, so Django
-issues a SQL ``INSERT`` statement. This creates a primary key, and
+issues an SQL ``INSERT`` statement. This creates a primary key, and
Django assigns that primary key to ``p``.
When the save occurs in statement 2, ``p`` already has a primary key
@@ -466,7 +466,7 @@ database::
>>> p.save(using='second') # Write a completely new object.
The second option is to use the ``force_insert`` option to ``save()``
-to ensure that Django does a SQL ``INSERT``::
+to ensure that Django does an SQL ``INSERT``::
>>> p = Person(name='Fred')
>>> p.save(using='first')