APEX Application Export: Supporting Objects and Static File Parity

Supported method for deterministic Supporting Objects execution

Use the APEX_APPLICATION_INSTALL API (or the import wizard) with the flags p_install_supporting_objects => TRUE and p_overwrite_existing => TRUE before importing the application export. This forces the Supporting Objects script to run even when the target schema already contains those objects.

Confirmed facts

• Setting p_install_supporting_objects => TRUE and p_overwrite_existing => TRUE (or choosing “Install Supporting Objects = Yes” and “Overwrite Existing = Yes” in the wizard) is the documented way to force execution.
• Static Workspace Files are not bundled with an application export; they must be exported at the workspace level via APEX_EXPORT.WORKSPACE (or Utilities → Export → Workspace) and imported with the corresponding workspace import.
• Importing by application alias preserves the logical alias but does not prevent the reset of internal component identifiers during a major APEX version upgrade; internal IDs are regenerated based on the new version’s metadata layout.

Likely explanation

When p_overwrite_existing => TRUE is set, the import process drops any existing Supporting Objects before recreating them, removing dependence on the pre‑existing schema state and making the import repeatable.

Workspace‑level files are treated as separate metadata; the application export mechanism has no option to include them without promoting them to Shared Components or recreating them as Static Application Files.

Alias‑based import only changes the logical identifier; the internal ID generation is tied to the APEX version’s metadata, so a major upgrade will still reset those IDs.

Steps to achieve full workspace parity

1. Export the application (including Supporting Objects) as usual.
2. Export the workspace‑level static files:

   BEGIN
     APEX_EXPORT.WORKSPACE(
       p_workspace => 'YOUR_WORKSPACE',
       p_file_name => 'workspace_export.sql');
   END;
   /

3. In the target environment, first import the workspace export to recreate the Static Workspace Files.
4. Before importing the application export, set the install flags:

   BEGIN
     APEX_APPLICATION_INSTALL.SET_APPLICATION_ID(p_application_id => NULL);
     APEX_APPLICATION_INSTALL.SET_OFFSET(p_offset => 0);
     APEX_APPLICATION_INSTALL.SET_SCHEMA(p_schema => 'TARGET_SCHEMA');
     APEX_APPLICATION_INSTALL.SET_WORKSPACE(p_workspace => 'TARGET_WORKSPACE');
     APEX_APPLICATION_INSTALL.SET_INSTALL_SUPPORTING_OBJECTS(p_install_supporting_objects => TRUE);
     APEX_APPLICATION_INSTALL.SET_OVERWRITE_EXISTING(p_overwrite_existing => TRUE);
   END;
   /

5. Run the application import (via SQL*Plus, SQLcl, APEX UI, or REST).
6. Verify Supporting Objects were (re)created:

   SELECT OBJECT_NAME, CREATED
     FROM USER_OBJECTS
     WHERE OBJECT_TYPE IN ('TABLE','VIEW','PROCEDURE','PACKAGE')
       AND CREATED >= (SELECT TIMESTAMP FROM APEX_APPLICATION_INSTALL WHERE APPLICATION_ID = :app_id);
   

7. Verify Static Workspace Files:

   SELECT *
     FROM APEX_APPLICATION_STATIC_FILES
     WHERE WORKSPACE = 'TARGET_WORKSPACE'
       AND FILE_NAME = 'expected_file_name';
   

Missing diagnostic detail

If the existing Supporting Objects contain data or customizations that must be preserved, using p_overwrite_existing => TRUE will cause data loss. In that case, you need to back up those objects or adjust the script to avoid dropping them. Please confirm whether you need to retain any existing Supporting Objects data before proceeding.