Как удалить apex oracle

Обновлено: 07.07.2024

The APEX_APPLICATION package is a PL/SQL package that implements the Oracle Application Express rendering engine. You can use this package to take advantage of many global variables. Table 1-1 describes the global variables available in the APEX_APPLICATION package .

Table 1-1 Global Variables Available in APEX_APPLICATION

Specifies the currently logged in user.

Specifies the ID of the currently running application.

Specifies the ID of the currently running page.

Specifies the schema to parse for the currently running application.

Specifies the value of the request variable most recently passed to or set within the show or accept modules.

Refers to the web browser's current language preference.

Refers to whether debugging is currently switched on or off. Valid values for the DEBUG flag are 'Yes' or 'No'. Turning debug on shows details about application processing.

Refers to the home page of an application. The Application Express engine redirects to this location if no page is given and if no alternative page is dictated by the authentication scheme's logic.

Used to display a link to a login page for users that are not currently logged in.

Refers to the virtual path the web server uses to point to the images directory distributed with Oracle Application Express.

Refers to the owner of the Application Express schema.

Refers to whether the Application Express engine is running in print view mode. This setting can be referenced in conditions to eliminate elements not desired in a printed document from a page.

Refers to the application attribute 'Proxy Server'.

Refers to the current date on the database server. this uses the DATE DATATYPE.

Refers to the Oracle schema used to connect to the database through the database access descriptor (DAD).

Specifies the application's global notification attribute.

Referencing Arrays

Items are typically HTML form elements such as text fields, select lists, and check boxes. When you create a new form item using a wizard, the wizard uses a standard naming format. The naming format provides a handle so you can retrieve the value of the item later on.

To create your own items, you can access them after a page is submitted by referencing APEX_APPLICATION.G_F01 to APEX_APPLICATION.G_F50 arrays. You can create your own HTML form fields by providing the input parameters using the format F01 , F02 , F03 and so on. You can create up to 50 input parameters ranging from F01 to F50 , for example:

Because the F01 to F50 input items are declared as PL/SQL arrays, you can have multiple items named the same value. For example:

Note that following PL/SQL code produces the same HTML as show in the previous example.

Referencing Values Within an On Submit Process

You can reference the values posted by an HTML form using the PL/SQL variable APEX_APPLICATION . G_F01 to APEX_APPLICATION . G_F50 . Because this element is an array, you can reference values directly, for example:

Converting an Array to a Single Value

You can also use Oracle Application Express public utility functions to convert an array into a single value. The resulting string value is a colon-separated list of the array element values. For example:

This function enables you to reference G_F01 to G_F50 values in an application process that performs actions on data. The following sample process demonstrates how values are inserted into a table:

HELP Procedure

This function outputs page and item level help text as formatted HTML. You can also use it to customize how help information is displayed in your application.

Table 1-2 describes the parameters available in the HELP procedure.

Table 1-2 HELP Parameters

The application ID that contains the page or item level help you want to output.

The page ID that contains the page or item level help you want to display.

Flag to determine if item level help is output. If this parameter is supplied, the value must be either 'YES' or 'NO', if not the default value is 'YES'.

Flag to determine if region headers are output (for regions containing page items). If this parameter is supplied, the value must be either 'YES' or 'NO', if not the default value is 'YES'.

Use this parameter to include HTML between the page level help text and item level help text.

Use this parameter to include HTML at the bottom of the output, after all other help.

Use this parameter to include HTML before every region section. Note this parameter is ignored if p_show_regions is set to 'NO'.

Use this parameter to include HTML after every region section. Note this parameter is ignored if p_show_regions is set to 'NO'.

Use this parameter to include HTML before every item label for item level help. Note this parameter is ignored if p_show_item_help is set to 'NO'.

Use this parameter to include HTML after every item label for item level help. Note this parameter is ignored if p_show_item_help is set to 'NO'.

Use this parameter to include HTML before every item help text for item level help. Note this parameter is ignored if p_show_item_help is set to 'NO'.

Use this parameter to include HTML after every item help text for item level help. Note this parameter is ignored if p_show_item_help is set to 'NO'.

The following example shows how to use the APEX_APPLICATION.HELP procedure to customize how help information is displayed.

In this example, the p_flow_step_id parameter is set to :REQUEST , which means that a page ID specified in the REQUEST section of the URL controls which page's help information to display (see note after example for full details on how this can be achieved).

Also, the help display has been customized so that the region sub-header now has a different color (through the p_before_region_html parameter) and also the ':' has been removed that appeared by default after every item prompt (through the p_after_prompt_html parameter).

To implement this type of call in your application, you can do the following:

Create a page that will be your application help page.

Create a region of type 'PL/SQL Dynamic Content' and add the APEX_APPLICATION.HELP call as PL/SQL Source.

Then you can add a 'Navigation Bar' link to this page, ensuring that the REQUEST value set in the link is &APP_PAGE_ID .

STOP_APEX_ENGINE Procedure

This procedure raises the exception apex_application . e_stop_apex_engine internally. You must raise that exception again, if you use a WHEN OTHERS exception handler.

Learn about troubleshooting after failed installation.

In a successful installation the following banner displays near the end of the installation:

To reinstall, you must either drop the Oracle Application Express database schemas, or run a script to completely remove Application Express from the database, depending upon the installation type.

Topics:


    Learn about reverting to Oracle Application Express to a previous release in the case of a failed upgrade installation.
    Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role and execute the SQL> @apxremov.sql command.

A.4.1 Reverting to a Previous Release After a Failed Upgrade Installation

Learn about reverting to Oracle Application Express to a previous release in the case of a failed upgrade installation.

In the case of a failed upgrade installation, you may want to revert Oracle Application Express to a previous release and then remove the schemas associated with the current release.

Topics:


    To verify, Start SQL*Plus and connect to the database and execute the command.
    Learn how to revert back to the release you want to revert to if you altered your images directory.
    Learn about reverting to Oracle Application Express prior release.
    You can remove the Oracle Application Express 5.1 schema after reverting to the prior release.

A.4.1.1 Verifying If You Have a Previous Release of Oracle Application Express

To verify, Start SQL*Plus and connect to the database and execute the command.

To verify whether you have a previous release of Application Express:

  1. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role. For example:

On UNIX and Linux:

If the query above returns any rows, the database contains a previous release of Oracle Application Express.

A.4.1.2 Reverting the Images Directory

Learn how to revert back to the release you want to revert to if you altered your images directory.

If you altered your images directory, revert it back to the release you want to revert to using the following methods:

For Oracle REST Data Services or mod_plsql :

If you altered your images directory, you must point the text alias /i/ back to images directory for the release you want to revert to.

For Embedded PL/SQL Gateway :

Run apex_epg_config.sql from the release directory you want to revert to, to restore the images of that release. See the Oracle Application Installation Guide for the release you want to revert to and find the section "Updating the Images Directory When Upgrading from a Previous Release."

A.4.1.3 Reverting to a Previous Release

Learn about reverting to Oracle Application Express prior release.

This section describes how to revert to a Oracle Application Express previous release.

Topics:


    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.
    Start SQL*Plus and connect to the database and execute the command.

A.4.1.3.1 Reverting to Release 1.5

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 1.5:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.2 Reverting to Release 1.6

Start SQL*Plus and connect to the database and execute the command.

To revert to a Oracle Application Express release 1.6:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.3 Reverting to Release 2.0

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 2.0:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.4 Reverting to Release 2.2

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 2.2:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.5 Reverting to Release 3.0

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 3.0:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex in the 3.0 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.6 Reverting to Release 3.1

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 3.1:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 3.1 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.7 Reverting to Release 3.2

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 3.2:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 3.2 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.8 Reverting to Release 4.0

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 4.0:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.9 Reverting to Release 4.1

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 4.1:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 4.1 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.10 Reverting to Release 4.2 in a non-CDB

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 4.2 in a non-CDB:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 4.2 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.11 Reverting to Release 4.2 in a CDB

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 4.2 in a CDB:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 4.2 source.
  3. Create a new text file in that directory named apx42dgrd1.sql consisting of the following:

On UNIX and Linux:

On UNIX and Linux:

A.4.1.3.12 Reverting to Release 5.0 in a non-CDB

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 5.0 in a non-CDB:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 5.0 source.
  3. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

A.4.1.3.13 Reverting to Release 5.0 in a CDB

Start SQL*Plus and connect to the database and execute the command.

To revert to a previous Oracle Application Express release 5.0 in a CDB:

  1. If you altered your images directory, revert it back to the release you want to revert to.
  2. Change your working directory to apex/core in the 5.0 source.
  3. Create a new text file in that directory named apx50dgrd1.sql consisting of the following:

On UNIX and Linux:

A.4.1.4 Removing the Oracle Application Express Release 5.1 Schema

You can remove the Oracle Application Express 5.1 schema after reverting to the prior release.

After you have reverted to the prior release you can remove the Oracle Application Express 5.1 schema.

Topics:


    Start SQL*Plus and connect to the database and execute DROP USER APEX_050100 CASCADE; .
    Create text files, start SQL*Plus and connect to the database execute @remove_apx51_usr.sql .

A.4.1.4.1 Removing the Oracle Application Express Release 5.1 Schema from a Non-CDB

Start SQL*Plus and connect to the database and execute DROP USER APEX_050100 CASCADE; .

To remove the release 5.1 schema from a non-CDB:

  1. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

Once you have removed the Oracle Application Express 5.1 schema, you can now attempt the upgrade again.

A.4.1.4.2 Removing the Oracle Application Express Release 5.1 Schema from a CDB

Create text files, start SQL*Plus and connect to the database execute @remove_apx51_usr.sql .

To remove the release 5.1 schema from a CDB:

  1. Create a new text file named remove_apx51_usr1.sql with the following contents:

On UNIX and Linux:

Once you have removed the Oracle Application Express 5.1 schema, you can now attempt the upgrade again.

A.4.2 Removing Oracle Application Express from the Database

Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role and execute the SQL> @apxremov.sql command.

This section describes how to remove the Oracle Application Express schema, synonyms, and users from the database without deleting the database.

Do not follow these steps if you have upgraded your database from a prior release, and still want to use the prior release of Oracle Application Express. For information about reverting to a prior release, see Reverting to a Previous Release . If you are not sure whether you have completed a new installation or an upgrade installation, follow the steps in Cleaning Up After a Failed Installation to verify if a previous release of Application Express exists in the database.

This appendix contains information on troubleshooting.

A.1 Reviewing a Log of an Installation Session

The apexins.sql script creates a log file in the apex directory using the naming convention installYYYY-MM-DD_HH24-MI-SS.log . In a successful installation, the log file contains the following text:

If the log file contains a few errors, it does not mean that your installation failed. Note that acceptable errors are noted as such in the log file.

A.2 Verifying the Validity of an Oracle Application Express Installation

You can verify the validity of an Oracle Application Express installation by running the following query:

If the result is VALID , you can assume the installation was successful.

A.3 Cleaning Up After a Failed Installation

In a successful installation the following banner displays at the end of the installation:

To reinstall, you must either drop the Oracle Application Express database schemas, or run a script to completely remove Application Express from the database, depending upon the installation type.

A.3.1 Removing Oracle Application Express from the Database

This section describes how to remove the Oracle Application Express schema, synonyms, and users from the database without deleting the database. If you are going to delete the database, then you must complete these steps.

To remove Oracle Application Express from the Oracle Database 12 c non-CDB where Oracle Application Express is not installed in the CDB$ROOT :

Change your working directory to $ORACLE_HOME/apex .

Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

Execute the following command:

After successfully removing Application Express using apxremov.sql , you must exit your current SQL*Plus session and reconnect prior to attempting another install using apexins.sql .

To remove Oracle Application Express from the database in 12 c multitenant architecture where Oracle Application Express is installed in the CDB$ROOT :

Change your working directory to $ORACLE_HOME/apex .

Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role:

On UNIX and Linux:

Execute the following command:

After successfully removing Application Express using apxremov_con.sql , you must exit your current SQL*Plus session and reconnect prior to attempting another install using apexins_con.sql .

A.4 Images Displaying Incorrectly in Oracle Application Express

If images in Oracle Application Express do not display correctly, you may have more than one definition of the /i/ alias. To address this issue:

If possible, rename the first instance of /i/ to a different alias name.

Alternatively, copy the images from the ORACLE_HOME \apex\images directory to the directory defined by the first /i/ alias.

A.5 Page Protection Violation

This may be caused by manual alteration of protected page items. If this error occurs after installation when trying to log into Application Express, then stop and start Oracle REST Data Services. If you are unsure of what caused this error, please contact the application administrator for assistance.

To learn more about stopping and starting Oracle REST Data Services, see Oracle REST Data Services Installation and Developer Guide .

Upgrade Blog posts about Oracle Application Express:

on how to customize a Single/Multitenant Database with less options.

But that is not the topic I would like to write about. I came across an pitfall in the past days twice.

Reason is simply that an Oracle Database 12.1.0.2 standard deployment will contain APEX 4.2.0 whereas the Oracle Cloud deployment in this scenario uses the more recent APEX version 5.0 already.

Having APEX installed into the CDB$ROOT was not a great idea. Actually it will cause you a lot of trouble and does not make much sense in the idea of Multitenant concept.

Oracle APEX Multitenant

Different APEX versions in Multitenant

First of all check your current APEX version with this query:

Find out in which container APEX is currently installed into:

Then choose the best solution for your environment to avoid trouble with APEX in a Multitenant environment.

Scenario

Migrate a PDB with containing an APEX 4.2 deployment into another CDB with APEX 5.0 already installed in the CDB$ROOT container (the standard deployment in the Oracle DBaaS Cloud).

Two Solutions

Basically I see two potential solutions:

Remove APEX from CDB$ROOT will remove it from all PDBs as well

The Oracle Documentation describes the path pretty straight forward.

More Scenarios

APEX installed commonly within CDB$ROOT

  • CDB1 has APEX 4.2 in CDB$ROOT
    CDB2 has APEX 5.0 in CDB$ROOT

APEX installed locally within the PDB only

  • CDB1 has NO APEX in CDB$ROOT
    CDB2 has APEX in CDB$ROOT

More Information

You can find more information via these links:

Having APEX locally in the PDB only offers you way more freedom and flexibility. All the complicated scenarios come up only when either the source has no APEX in the CDB$ROOT (APEX locally in the PDB) but the target has any version (most likely a different one) or the target has no APEX in the CDB$ROOT but the source had it. And even more fun, both CDBs have APEX in the CDB$ROOT but at different versions.

This can be totally avoided by NEVER having APEX installed in your CDB$ROOT.

Читайте также: