Recently we developed Oracle APEX application in our APEX 18.1 environment. Trying to share the tool with one of our customers, we realised that they are still using 5.1.4 and won’t be able to update within short time.

Of course, the right way would be to update target version of the APEX installation. But maybe there are reasons on customers side you cannot influence. In that case you might run into the same question as we did.

So, we had source instance 18.1 and target instance 5.1.4. Then the next question is

Is it feasible to import this application export file from a higher version
into a lower version?

May be not directly. If one does it, the below error appears

To make it workable there are some options:

1. Recreate everything in lower version instance

    > Maybe this is a suitable choice for simple application, but for advanced and practical application one need to put more effort, time and duplication of work

2. Do some modifications in export file

    > You need to know the reason for the above error first so that one can do necessary changes in export file. As well as one has to know the newly added features in higher version

So here is the reason:

When you import a file, it will first check for compatibility mode, which is defined by release and version parameters of procedure



So, need to find this procedure in our export file and change these parameter values as required.

Follow the below process to know how and where to change required details:

    > Create one dummy application in target instance and export it

    > Compare export files from source instance and target instance as shown in below table. It can be seen that the p_version and p_release parameter values are different in both the files

In source instance (18.1)  begin wwv_flow_api.import_begin (  p_version_yyyy_mm_dd=>'2018.04.04' ,p_release=>'' ,p_default_workspace_id=>XXXXXXX ,p_default_application_id=>XXXXXX ,p_default_owner=>'XXX' ); end;

In target instance (5.1.4) begin wwv_flow_api.import_begin (  p_version_yyyy_mm_dd=>'2016.08.24' ,p_release=>'' ,p_default_workspace_id=>XXXXXXX ,p_default_application_id=>XXXXXXX ,p_default_owner=>'XXXX' ); end;

    > So, change the parameter values of import_begin procedure in source export file. For e.g., the release and the version parameters in export file
from ‚‘  to ‚‘ and
from    ‚2018.04.04‘    to ‚2016.08.24‘ respectively

    > Import edited export file in target instance this time it will allow you to run the script

> But with some errors. For e.g., see below image

> To solve this, simply open the export file and remove the parameter which causes the error

> Repeat editing the application export file to remove or edit parameters that are not supported in the target instance until it imported successfully

> Find all the changed parameters by using below query from both the instances and compare it and delete or modify newly added parameters

> Always modify or eliminate as little as possible parameters to minimize loss of functionality

> There may also occur errors regarding check constraints, like this:

> Analysing the constraint in dictionary and comparing with export code shows the difference:

> After importing, try to run imported application

However, once you have successfully imported application, you may or may not get different types of errors. It depends on your source application and your source- and target-version.

For example, we got following error:

So what we did was to search for <“emit_language_selector_list”> in the export file and eliminated whole procedure call <“wwv_flow_api.create_page_plug”> for this element.

So what we did was to search for <“emit_language_selector_list”> in the export file and eliminated whole procedure call <“wwv_flow_api.create_page_plug”> for this element.

So what we did was to search for <“emit_language_selector_list”> in the export file and eliminated whole procedure call <“wwv_flow_api.create_page_plug”> for this element.

After fixing the technical errors there may be one problem left with some unexpected or unusual outfit like this:

To fix this problem, go to “Shared Components” ► “Themes” and choose your current theme (probably UT – 42) and click “Refresh Theme”:

So, in few minutes complete application is in target instance.

Test your application to ensure everything works fine.

Maybe it is not the rigorous way to change the export file manually but the above process makes our work very simple and enables implementation in a straightforward manner at the customer desk.

Finally, some notes:

We have to point out, that this is a completely unsupported way, this is not recommended, we do not give any warranty, but if you run into that problem it might be a possible approach to help you out.

Of course, one should test the modified application carefully and very detailed to make sure, no functionality has gone lost and everything works fine.

We do understand this article as a way to learn how APEX – and especially the import-/export-file works.


Keine Kommentare

Ähnliche Beiträge