replace "Oracle" with "Oracle Database"

PhilippSalvisberg · PhilippSalvisberg · commit 75169628e8eb · 2022-08-12T14:22:02.000+02:00
diff --git a/docs/2-naming-conventions/naming-conventions.md b/docs/2-naming-conventions/naming-conventions.md
@@ -8,14 +8,14 @@
 4. Avoid long abbreviations. Abbreviations should be shorter than 5 characters.
 5. Any abbreviations must be widely known and accepted. 
 6. Create a glossary with all accepted abbreviations.
-7. Never use Oracle keywords as names. A list of Oracles keywords may be found in the dictionary view `v$reserved_words`.
+7. Never use keywords as names. A list of keywords may be found in the dictionary view `v$reserved_words`.
 8. Avoid adding redundant or meaningless prefixes and suffixes to identifiers.<br/>Example: `create table emp_table`.
 9. Always use one spoken language (e.g. English, German, French) for all objects in your application.
 10. Always use the same names for elements with the same meaning.
 
 ## Naming Conventions for PL/SQL
 
-In general, Oracle is not case sensitive with names. A variable named personname is equal to one named PersonName, as well as to one named PERSONNAME. Some products (e.g. TMDA by Trivadis, APEX, OWB) put each name within double quotes (&quot;) so Oracle will treat these names to be case sensitive. Using case sensitive variable names force developers to use double quotes for each reference to the variable. Our recommendation is to write all names in lowercase and to avoid double quoted identifiers.
+In general, the Oracle Database is not case sensitive with names. A variable named personname is equal to one named PersonName, as well as to one named PERSONNAME. Some products (e.g. TMDA by Trivadis, APEX, OWB) put each name within double quotes (&quot;) so the Oracle Database will treat these names to be case sensitive. Using case sensitive variable names force developers to use double quotes for each reference to the variable. Our recommendation is to write all names in lowercase and to avoid double quoted identifiers.
 
 A widely used convention is to follow a `{prefix}variablecontent{suffix}` pattern.
 
diff --git a/docs/4-language-usage/2-variables-and-types/1-general/g-2130.md b/docs/4-language-usage/2-variables-and-types/1-general/g-2130.md
@@ -13,7 +13,7 @@ Your code will be easier to read as the usage of a variable/constant may be deri
 
 Type               | Usage
 ------------------ | -----
-`ora_name_type`    | Object corresponding to the Oracle naming conventions (table, variable, column, package, etc.).
+`ora_name_type`    | Object corresponding to the Oracle Database naming conventions (table, variable, column, package, etc.).
 `max_vc2_type`     | String variable with maximal VARCHAR2 size.
 `array_index_type` | Best fitting data type for array navigation.
 `id_type`          | Data type used for all primary key (id) columns.
diff --git a/docs/4-language-usage/2-variables-and-types/1-general/g-2190.md b/docs/4-language-usage/2-variables-and-types/1-general/g-2190.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Be careful about your use of Oracle-specific data types like `rowid` and `urowid`. They might offer a slight improvement in performance over other means of identifying a single row (primary key or unique index value), but that is by no means guaranteed. 
+Be careful about your use of Oracle Database specific data types like `rowid` and `urowid`. They might offer a slight improvement in performance over other means of identifying a single row (primary key or unique index value), but that is by no means guaranteed. 
 
 Use of `rowid` or `urowid` means that your SQL statement will not be portable to other SQL databases. Many developers are also not familiar with these data types, which can make the code harder to maintain. 
 
diff --git a/docs/4-language-usage/2-variables-and-types/3-character-data-types/g-2330.md b/docs/4-language-usage/2-variables-and-types/3-character-data-types/g-2330.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Today zero-length strings and `null` are currently handled identical by Oracle. There is no guarantee that this will still be the case in future releases, therefore if you mean `null` use `null`.
+Today zero-length strings and `null` are currently handled identical by the Oracle Database. There is no guarantee that this will still be the case in future releases, therefore if you mean `null` use `null`.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/2-variables-and-types/5-large-objects/g-2510.md b/docs/4-language-usage/2-variables-and-types/5-large-objects/g-2510.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-`long` and `long raw` data types have been deprecated by Oracle since version 8i - support might be discontinued in future Oracle releases.
+`long` and `long raw` data types have been deprecated by the Oracle Database since version 8i - support might be discontinued in future Oracle Database releases.
 
 There are many constraints to `long` datatypes in comparison to the `lob` types.
 
diff --git a/docs/4-language-usage/4-control-structures/1-cursor/g-4130.md b/docs/4-language-usage/4-control-structures/1-cursor/g-4130.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Any cursors left open can consume additional memory space (i.e. SGA) within the database instance, potentially in both the shared and private SQL pools. Furthermore, failure to explicitly close cursors may also cause the owning session to exceed its maximum limit of open cursors (as specified by the `open_cursors` database initialization parameter), potentially resulting in the Oracle error of “ORA-01000: maximum open cursors exceeded”. 
+Any cursors left open can consume additional memory space (i.e. SGA) within the database instance, potentially in both the shared and private SQL pools. Furthermore, failure to explicitly close cursors may also cause the owning session to exceed its maximum limit of open cursors (as specified by the `open_cursors` database initialization parameter), potentially resulting in the Oracle Database error of “ORA-01000: maximum open cursors exceeded”. 
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/4-control-structures/1-cursor/g-4140.md b/docs/4-language-usage/4-control-structures/1-cursor/g-4140.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Oracle provides a variety of cursor attributes (like `%found` and `%rowcount`) that can be used to obtain information about the status of a cursor, either implicit or explicit. 
+The Oracle Database provides a variety of cursor attributes (like `%found` and `%rowcount`) that can be used to obtain information about the status of a cursor, either implicit or explicit. 
 
 You should avoid inserting any statements between the cursor operation and the use of an attribute against that cursor. Interposing such a statement can affect the value returned by the attribute, thereby potentially corrupting the logic of your program. 
 
diff --git a/docs/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4220.md b/docs/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4220.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-`decode` is an Oracle specific function hard to understand and restricted to SQL only. The “newer” `case` function is much more common, has a better readability and may be used within PL/SQL too. Be careful that `decode` can handle `null` values, which the simple `case` cannot - for such cases you must use the searched `case` and `is null` instead.
+`decode` is an Oracle Database specific function hard to understand and restricted to SQL only. The “newer” `case` function is much more common, has a better readability and may be used within PL/SQL too. Be careful that `decode` can handle `null` values, which the simple `case` cannot - for such cases you must use the searched `case` and `is null` instead.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/5-exception-handling/g-5010.md b/docs/4-language-usage/5-exception-handling/g-5010.md
@@ -15,7 +15,7 @@ This kind of framework should include
 * Logging (different channels like table, mail, file, etc. if needed)
 * Error Raising
 * Multilanguage support if needed
-* Translate Oracle error messages to a user friendly error text
+* Translate Oracle Database error messages to a user friendly error text
 * Error repository
 
 ## Example (bad)
diff --git a/docs/4-language-usage/5-exception-handling/g-5030.md b/docs/4-language-usage/5-exception-handling/g-5030.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-This is error-prone because your local declaration overrides the global declaration. While it is technically possible to use the same names, it causes confusion for others needing to read and maintain this code. Additionally, you will need to be very careful to use the prefix `standard` in front of any reference that needs to use Oracle’s default exception behavior.
+This is error-prone because your local declaration overrides the global declaration. While it is technically possible to use the same names, it causes confusion for others needing to read and maintain this code. Additionally, you will need to be very careful to use the prefix `standard` in front of any reference that needs to use the default exception behavior of the Oracle Database.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/5-exception-handling/g-5050.md b/docs/4-language-usage/5-exception-handling/g-5050.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-If you are not very organized in the way you allocate, define and use the error numbers between  20999 and  20000 (those reserved by Oracle for its user community), it is very easy to end up with conflicting usages. You should assign these error numbers to named constants and consolidate all definitions within a single package. When you call `raise_application_error`, you should reference these named elements and error message text stored in a table. Use your own raise procedure in place of explicit calls to `raise_application_error`. If you are raising a "system" exception like `no_data_found`, you must use `raise`. However, when you want to raise an application-specific error, you use `raise_application_error`. If you use the latter, you then have to provide an error number and message. This leads to unnecessary and damaging hard-coded values. A more fail-safe approach is to provide a predefined raise procedure that automatically checks the error number and determines the correct way to raise the error. 
+If you are not very organized in the way you allocate, define and use the error numbers between  20999 and  20000 (those reserved by the Oracle Database for its user community), it is very easy to end up with conflicting usages. You should assign these error numbers to named constants and consolidate all definitions within a single package. When you call `raise_application_error`, you should reference these named elements and error message text stored in a table. Use your own raise procedure in place of explicit calls to `raise_application_error`. If you are raising a "system" exception like `no_data_found`, you must use `raise`. However, when you want to raise an application-specific error, you use `raise_application_error`. If you use the latter, you then have to provide an error number and message. This leads to unnecessary and damaging hard-coded values. A more fail-safe approach is to provide a predefined raise procedure that automatically checks the error number and determines the correct way to raise the error. 
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/7-stored-objects/5-oracle-supplied-packages/g-7510.md b/docs/4-language-usage/7-stored-objects/5-oracle-supplied-packages/g-7510.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-The signature of Oracle-supplied packages is well known and therefore it is quite easy to provide packages with the same name as those from Oracle doing something completely different without you noticing it.
+The signature of Oracle supplied packages is well known and therefore it is quite easy to provide packages with the same name as those from Oracle doing something completely different without you noticing it.
 
 ## Example (bad)
 
diff --git a/docs/7-tool-support/1-db-codecop-sqldev.md b/docs/7-tool-support/1-db-codecop-sqldev.md
@@ -20,7 +20,7 @@ The results are presented in an additional tabbed panel. One tab shows all guide
 
 ## Examples
 
-Open an Oracle PL/SQL or SQL script in a SQL Developer editor and press Ctrl-Shift-C to check your code against the Trivadis PL/SQL & SQL guidelines.
+Open a PL/SQL or SQL script in a SQL Developer editor and press Ctrl-Shift-C to check your code against the Trivadis PL/SQL & SQL guidelines.
 
 ![Check](../images/tvdcc-sqldev-check.png)
 
