Removed references to Oracle 11, 12, 18 in documentation.

Jacek Gębal · Jacek Gębal · commit e5b966b01a19 · 2026-04-22T13:40:18.000+03:00
diff --git a/docs/userguide/annotations.md b/docs/userguide/annotations.md
@@ -46,7 +46,7 @@ package test_package is
   --%disabled
   procedure my_first_procedure;
 
-  $if dbms_db_version.version >= 12 $then --This is ok - annotation before procedure 
+  $if dbms_db_version.version >= 19 $then --This is ok - annotation before procedure 
   --%test() 
   procedure my_first_procedure;
   $end
@@ -71,7 +71,7 @@ package test_package is
   procedure proc1;
 
   --%test() --This is wrong as there is a compiler directive between procedure and annotation
-  $if dbms_db_version.version >= 12 $then  
+  $if dbms_db_version.version >= 19 $then  
   procedure proc_12;
   $end
 
@@ -1755,7 +1755,7 @@ The `--%throws` annotation allows you to specify a list of exceptions as one of:
 - number literals - example `--%throws(-20134)`
 - variables of type exception defined in a package specification - example `--%throws(exc_pkg.c_exception_No_variable)`
 - variables of type number defined in a package specification - example `--%throws(exc_pkg.c_some_exception)`
-- [predefined oracle exceptions](https://docs.oracle.com/cd/E11882_01/timesten.112/e21639/exceptions.htm#CIHFIGFE) - example `--%throws(no_data_found)`
+- [predefined oracle exceptions](https://docs.oracle.com/en//database/oracle/oracle-database/19/lnpls/predefined-exceptions.html) - example `--%throws(no_data_found)`
 
 The annotation is ignored, when no valid arguments are provided. Examples of invalid annotations `--%throws()`,`--%throws`, `--%throws(abe, 723pf)`.
 
diff --git a/docs/userguide/coverage.md b/docs/userguide/coverage.md
@@ -1,6 +1,6 @@
 ![version](https://img.shields.io/badge/version-v3.2.01.4361--develop-blue.svg)
 
-utPLSQL comes with a built-in coverage reporting engine. The code coverage reporting uses package DBMS_PROFILER (and DBMS_PLSQL_CODE_COVERAGE on Oracle database version 12.2 and above) provided with Oracle database.
+utPLSQL comes with a built-in coverage reporting engine. The code coverage reporting combines data from package DBMS_PROFILER and DBMS_PLSQL_CODE_COVERAGE.
 Code coverage is gathered for the following source types:
 
 * package bodies
@@ -27,7 +27,7 @@ The following code coverage reporters are supplied with utPLSQL:
 * `ut_coverage_cobertura_reporter`  - generates a basic Cobertura coverage (http://cobertura.sourceforge.net/xml/coverage-04.dtd) report providing detailed information on code coverage with line numbers. This coverage report is designed to be consumed by services like TFS and Jenkins. Check this link for an example of XML generated by Java: https://raw.githubusercontent.com/jenkinsci/cobertura-plugin/master/src/test/resources/hudson/plugins/cobertura/coverage-with-data.xml
 
 ## Security model
-utPLSQL code coverage uses DBMS_PROFILER to gather information about the execution of code under test and therefore follows the [DBMS_PROFILER's Security Model](https://docs.oracle.com/database/121/ARPLS/d_profil.htm#ARPLS67465).
+utPLSQL code coverage uses DBMS_PROFILER to gather information about the execution of code under test and therefore follows the [DBMS_PROFILER's Security Model](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_PROFILER.html#GUID-DEE5EA97-14AA-4AF2-A5F7-4AB1D004B99F).
 In order to be able to gather coverage information, the user executing unit tests needs to be either:
 
 * The owner of the code that is being tested
@@ -63,14 +63,15 @@ The report allow you to navigate to each source file and inspect line by line co
 ![Coverage Details page](../images/coverage_html_details.png)
 
 
-### Oracle 12.2 extended coverage with profiler and block coverage
-Using data collected from profiler and block coverage running parallel we are able to enrich information about coverage.
-For every line recorded by the profiler if we have a partially covered same line in block coverage we will display that information
-presenting line as partially covered, displaying number of block and how many blocks have been covered in that line.The feature will be automatically enabled in the Oracle database version 12.2 and higher, for older versions current profiler will be used.
+### Partial Coverage
 
-utPLSQL installation automatically creates tables needed by `dbms_plsql_code_coverage` on databases in versions above 12c Release 1.
-Due to security model of `dbms_plsql_code_coverage` package, utPLSQL grants access to those tables and creates synonyms for those tables.
-The access and synonyms will be public when using the headless installation. This approach avoids complexity of forcing every user of utPLSQL framework to create tables on their own.    
+#### What it does
+Partial coverage combines two data sources — the profiler and block coverage — to give you a more detailed picture of which parts of your code have been tested.
+When a line appears in both sources, and block coverage shows it was only partially covered, the display will reflect that: you'll see the line marked as partially covered, along with how many blocks on that line were executed out of the total.
+
+#### Setup and permissions
+utPLSQL automatically creates the tables required by Oracle's dbms_plsql_code_coverage package — you don't need to create them manually.
+Because of how dbms_plsql_code_coverage handles security, utPLSQL also takes care of granting access to those tables and creating the necessary synonyms. In a headless installation, both the grants and synonyms are made public, keeping things simple without requiring every utPLSQL user to set up their own tables.
 
 Sample output:
 
diff --git a/docs/userguide/expectations.md b/docs/userguide/expectations.md
@@ -648,9 +648,7 @@ Syntax:
 
 `ut.expect( a_actual ).to_be_like( a_mask [, a_escape_char] )`
 
-Parameters `a_mask` and `a_escape_char` represent valid parameters of the [Oracle LIKE condition](https://docs.oracle.com/database/121/SQLRF/conditions007.htm#SQLRF52142).
-
-If you use Oracle Database version 11.2.0.4, you may run into Oracle Bug 14402514: WRONG RESULTS WITH LIKE ON CLOB USING ESCAPE CHARACTER. In this case we recommend to use `match` instead of `be_like`.
+Parameters `a_mask` and `a_escape_char` represent valid parameters of the [Oracle LIKE condition](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Pattern-matching-Conditions.html).
 
 Usage:
 ```sql linenums="1"
@@ -1224,9 +1222,7 @@ utPLSQL is capable of comparing compound data-types including:
 - Comparison of cursor returning `TIMESTAMP` **columns** against cursor returning `TIMESTAMP` **bind variables** requires variables to be cast to proper precision. This is an Oracle SQL - PLSQL compatibility issue and usage of CAST is the only known workaround for now. See [Comparing cursor data containing TIMESTAMP bind variables](#comparing-cursor-data-containing-timestamp-bind-variables) for examples.    
 - To compare nested table/varray type you need to convert it to `anydata` by using `anydata.convertCollection()`  
 - To compare object type you need to convert it to `anydata` by using `anydata.convertObject()`  
-- It is possible to compare PL/SQL records, collections, varrays and associative arrays. To compare this types of data, use cursor comparison feature of utPLSQL and TABLE operator in SQL query
-    - On Oracle 11g Release 2 - pipelined table functions are needed (see section [Implicit (Shadow) Types in this artcile](https://oracle-base.com/articles/misc/pipelined-table-functions))
-    - On Oracle 12c and above - use [TABLE function on nested tables/varrays/associative arrays of PL/SQL records](https://oracle-base.com/articles/12c/using-the-table-operator-with-locally-defined-types-in-plsql-12cr1) 
+- It is possible to compare PL/SQL records, collections, varrays and associative arrays. To compare this types of data, use cursor comparison feature of utPLSQL and [TABLE operator in SQL query](https://oracle-base.com/articles/12c/using-the-table-operator-with-locally-defined-types-in-plsql-12cr1) 
 - utPLSQL is not able to distinguish between NULL and whitespace-only column/attribute value when comparing compound data. This is due to Oracle limitation on of XMLType.  
   See [issue #880](https://github.com/utPLSQL/utPLSQL/issues/880) for details. *Note: This behavior might be fixed in future releases, when utPLSQL is no longer depending on XMLType for compound data comparison.*
 
@@ -1763,7 +1759,7 @@ FAILURE
 
 ## Comparing Json objects
 
-utPLSQL is capable of comparing json data-types of `json_element_t` **on Oracle 12.2 and above**, and also `json` **on Oracle 21 and above**
+utPLSQL is capable of comparing json data-types of `json_element_t`, and also `json` **on Oracle 21 and above**
 
 !!! note
     Whenever a database is upgraded to compatible version the utPLSQL needs to be reinstalled to pick up json changes. E.g. upgrade from 18c to 21c to enable `json` type compare. 
diff --git a/docs/userguide/install.md b/docs/userguide/install.md
@@ -2,19 +2,11 @@
 
 ## Supported database versions
 
-utPLSQL is continuously tested against following versions of Oracle databases
+- Oracle Database 19c or newer (SE/EE/Cloud/Free)
 
-* 11g R2 
-* 12c
-* 12c R2
-* 18c
-* 19c
+We do our best to assure full compatibility with **actively supported** versions of Oracle databases. 
+See [this page](https://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf#page=6) for Oracle Database Releases and their Support Lifetime by Oracle.
 
-We do our best to assure full compatibility with supported versions of Oracle databases [See](http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf#page=6)
-
-## Requirements
-
-utPLSQL will run on any Oracle Database version 11g relase 2 or above.
 
 ### Licensed features required
 
@@ -179,7 +171,7 @@ If the installing user and utPLSQL owner is one and the same, the user must have
   
 In addition, the user must be granted the execute privilege on `DBMS_LOCK` and `DBMS_CRYPTO` packages.
     
-utPLSQL is using [DBMS_PROFILER tables](https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/d_profil.htm#i999476) for code coverage. The tables required by DBMS_PROFILER will be created in the installation schema unless they already exist.
+utPLSQL is using [DBMS_PROFILER tables](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_PROFILER.html) for code coverage. The tables required by DBMS_PROFILER will be created in the installation schema unless they already exist.
 
 It is up to DBA to maintain the storage of the profiler tables.
 
@@ -274,7 +266,7 @@ select
 ## Additional requirements
 
 In order to use the Code Coverage functionality of utPLSQL, users executing the tests must have the CREATE privilege on the PLSQL code that the coverage is gathered on.
-This is a requirement of [DBMS_PROFILER package](https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/d_profil.htm#i999476).
+This is a requirement of [DBMS_PROFILER package](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_PROFILER.html#GUID-DEE5EA97-14AA-4AF2-A5F7-4AB1D004B99F).
 
 In practice, user running tests for PLSQL code that he does not own, needs to have CREATE ANY PROCEDURE/CREATE ANY TRIGGER privileges.
 Running code coverage on objects that the user does not own will **not produce any coverage information** without those privileges.
