Splitting Export Files into Separate SQL Scripts

Learn about splitting application, page, and component export files into separate SQL scripts.

Splitting application, page, and component exports into separate files can be very useful if you are managing files using a version control system such as Apache Subversion (SVN) or Git. This approach enables you to check in files to the repository as you make changes. For example, suppose a developer modifies Page 1 and a list of values called Categories. If you export the application as separate files, you can commit only the two files with changes.

Another benefit of splitting exports into separate files is that it enables you to take an incremental approach to deployment. Rather than having to re-install an entire application for a minor change (for example, fixing a typo on a label), only the file containing the fix needs to be run on the destination system.

You can split application, page, and component exports into separate files as follows:

• Applications - Select the Split into Multiple Files flag to export the application as a ZIP archive containing separate files for each page, shared component, and so on. You can unzip the Zip file on your local file system and then commit updated files to your source code repository.

• Pages and other Components - Select the Export as Zip flag to export the selected components as a ZIP archive containing separate SQL files for each component.

See Also: Exporting and Importing from a Command Line in Oracle APEX Administration Guide

Export Directory Structure

Exporting an application, page, or components into separate scripts creates a directory structure organized by component type.

See Also: Directory Structure When Splitting Export Files into Separate Scripts

Export File Names

Export files use the following naming conventions:

• Application Export - Named using the application ID. For example, an application with the ID 326 would be named: f326.sql or f326.zip.

• Page Export - Named after the application ID and page number. For example, exporting page 4 in an application with the ID 326 would be named: f326_page_4.sql or f326_page_4.zip.

• Component Export - If you select multiple components, the name uses the application ID and components. For, example, multiple components in an application with the ID 326 would be named: f326_components.sql or f326_components.zip.

  Component file names are based on the name specified in App Builder. In general, special characters are removed and spaces are replaced with underscores.

  If you rename a component in App Builder, the next time you create a Component Export, a new file name is used. For example, if you have breadcrumb named Menu and you create a Component Export, the file would be named menu.sql. If you rename that breadcrumb Main Menu, the new Component Export is named main_menu.sql. If you are using a version control system, you are responsible for applying the proper commands to rename or move the original file to maintain the history.

Generated Installation Scripts

Exporting create a number of installation scripts. Depending upon the type of export, the installation scripts are named one of the following:

• Application Export - install.sql

• Page Export - install_page.sql

• Component Export - install_component.sql

In addition to installation files, each export includes two files which are useful when developing custom patch scripts:

• set_environment.sql

• end_environment.sql

These files contain internal code that help improve performance. These scripts set internal variables and perform security checks at one time for the entire import. Without these scripts, the internal variables check will be executed for each file you run.

A sample custom installation file might resemble following:

@@application/set_environment.sql
@@application/pages/page_00001.sql
@@application/pages/page_00023.sql
@@application/pages/page_00095.sql
@@application/end_environment.sq