This content has been marked as final. Show 20 replies
I provided all the requested information, all packaged applications are AVAILABLE, no errors in the 4.2.1 upgrade log, everything installed succesfully. Now I am being asked to "Can you send me your packaged application and so i can try in my end"! I am not sure how to respond to this since packaged applications are part of the APEX distribution, it is not something the customer should be asked for. Almost seems as if Oracle Support does not understand what packaged application is referring to in this context!
I can appreciate your reluctance to pursue a support case on a public forum but I really believe it would be faster and more efficient to cut out the middleman (in a manner of speaking) and for us to work directly with each other i.e. I can provide any diagnostics you need.
OK I did some more digging and found a workaround to install these apps. SR has been updated.
I used the command line export to export out the packaged applications one-by-one using the application ids obtained from the row key column returned by the above query.
select row_key,app_name from apex_040200.wwv_flow_pkg_applications where app_status = 'AVAILABLE' and app_type='DB' order by row_key;
Using the APEX GUI, I was able to successfully import and install these application export files (f8950.sql, f7010.sql, etc) and supporting objects into my workspace and they work just fine.
This would seem to indicate that all the plumbing (export, import, parse, etc) works fine, it is just the APEX GUI install wizard has a bug that prevents it from installing these apps.
Huh, simply changing the OHS dads.conf to use APEX_PUBLIC_USER for the DAD instead of the legacy HTMLDB_PUBLIC_USER fixed the issue, never would have guessed.
The installation wizard could certainly handle this better by checking pre-requisites and warning that the app won't install instead of throwing cryptic errors that took weeks to troubleshoot and resolve.
Also, the built-in installation wizard has many restrictions
1. You can’t change the app owner schema, it installs everything into the first schema associated with the workspace, we may not want all the sample app's database objects to be created in this schema
2. The apps are locked so you can’t see the source code without unlocking them, more pointing and clicking.
3. You can’t change the application id. We have created app id ranges for organizing apps and need control over the app id.
In light of these restrictions, I prefer the solution I came up with (see my prior post in this thread) to manually install the apps.
>> … never would have guessed
Apparently, so are them ;)
♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.
♦ Author of Oracle Application Express 3.2 – The Essentials and More
Arie - Yeah, I am pretty sure Oracle Support was just going through the standard trouble-shooting motions (reboot computer, re-install, verify pre-requisites) and hit paydirt! I still think this is a very silly bug and the packaged installation wizard should verify the DAD user especially if it is going to crash and burn so spectacularly! In other words, apex_public_user should be hard-coded anywhere in the product. Its only purpose appears to be to evaluate the authentication (or authorization?) condition Is Public User and since the application attribute (Edit Application Properties > Security > Public User) is user-configurable (as is the DAD setting), I should be able to set both of them to, say, FOOBAR, and still be able to install packaged applications.
Oh well, it is not a big deal in the grand scheme of things but the resolution definitely caught me by surprise. Hope Oracle considers fixing this in the next release.