Joel Kallman

Most often, patch sets for Oracle Application Express are used to correct defects (i.e., fix bugs) identified in a release.  It's rare for features to be introduced or behavior to change.  But in the case of Oracle Application Express 4.2.2 and later, there is a change in behavior that is worth discussing, namely, the change in behavior to the Image Prefix application attribute.  This has been raised by Oracle Support three times in the past couple weeks, so we have certainly created some confusion amongst our customers.


In a Nutshell

• In Application Express 4.2.2, if your image prefix application attribute equals the instance-wide image prefix attribute, it will be set to null in your application.
• At runtime, if the image prefix application attribute is null, the APEX engine will use the instance-wide image prefix attribute as your application's image prefix.
• This was done to facilitate ease of movement of applications across varying instances.

Background

Every instance of Oracle Application Express has an instance-wide image prefix.  This image prefix is used by Oracle Application Express to specify the directory location of the Application Express images directory.  This image prefix ultimately correlates to a virtual directory or equivalent on the Web server, and this virtual directory directly maps to the 'images' directory shipped with an APEX distribution and staged on the Web server.  This image prefix is specified at APEX installation time, but it can be adjusted later if necessary.  This image prefix is usually always /i/.

For example, if you go to the Login page of apex.oracle.com and look at the source of that page, you'll see numerous references to images and files of the form /i/...  The HTML for the logo in the upper left is:

<img alt="Application Express" height="20" src="/i/apex_ui/apexlogo.png" width="280" />

There is a virtual directory on the Web server of apex.oracle.com, which maps /i/ to a virtual directory.  This virtual directory maps to a physical directory on the Web server, which contains the entire 'apex/images' directory from the APEX distribution.

The 'apex/images' directory changes from release to release.  The 'apex/images' directory from an APEX 4.1 release is only usable with APEX 4.1.  The 'apex/images' directory fron an APEX 4.2 release is only usable with APEX 4.2.  You can try and use it with APEX 4.1, but you'll definitely see odd results, if anything at all.

The image prefix is also an attribute of the user interface of an application.  This image prefix is used during the runtime of the APEX application, and is used to determine the image prefix for that application.  99% of the time, this image prefix application attribute equals the instance-wide image prefix (typically, /i/), but it could be different too.  It could even be wrong!  If you change your image prefix attribute to '/foobar/' and then run your application, you'll see that all the references to images and static files in the HTML source of your application all reference '/foobar/'.  I suspect you'd get a page with broken images and references everywhere, and in the worst case, you may get what appears to be a blank page.


Using the Image Prefix

Now here's where it gets interesting.  Even though the documentation recommends an image prefix of /i/, it isn't absolutely mandatory.  So let's say that for my APEX 4.1 instance, I use an image prefix of /i_old/, and for my APEX 4.2.2 instance, I use an image prefix of /i_new/.  And also let's assume that these instances use totally distinct Web servers.  If I export an application from my APEX 4.1 instance and import it into my APEX 4.2.2 instance, I will need to update the image prefix application attribute before I can run it in the APEX 4.2.2 instance.  Why is that?  Because my application image prefix is /i_old/, and that isn't defined on the Web server for my APEX 4.2.2 instance.

For those who have participated in the Application Express Early Adopter program before, you'll remember that the image prefix was /i_ea/ or something like that.  When you imported your existing APEX application into the Early Adopter instance, you had to adjust the image prefix of your application to be equal to the instance-wide image prefix, /i_ea/.

For enterprises which host multiple APEX instances via one Web server, they have an equally difficult problem.  They may have image prefixes of /i40/, /i41/, /i42, and wish to freely move and test applications without having to adjust the image prefix attribute every time they import an application.  It's cumbersome and unnecessary.


What has changed in APEX 4.2.2 and Later

Upon upgrade to Application Express 4.2.2 or application of the 4.2.2 patch set, the image prefix attribute of applications will be set to null if their value is equal to the instance-wide image prefix.  In the simplest example, if the instance-wide image prefix is /i/ and your application's image prefix attribute is /i/, the application attribute will be set to null in 4.2.2.

If you try to edit the image prefix application attribute and set it to the instance-wide image prefix (e.g., /i/), it won't be saved and it will be null.  Only if you change it to something other than the instance-wide image prefix will a non-null value be saved.

The utility script to adjust the image prefix instance-wide setting, apex/utilities/reset_image_prefix.sql, now only adjusts the instance setting and nothing more.  No image prefix application attributes are touched.  It's unnecessary, because a null image prefix application attribute means "use the setting of the APEX instance".

Now, if you use a non-standard image prefix for your APEX instance, you can import your application into any other instance without having to be aware of what the image prefix is on the target instance.


Now with that said.....I wish you a nice Memorial Day.

Oracle Application Express 4.2.2 is now released and available for download.  If you wish to download the full release of Oracle Application Express 4.2.2, you can get it from the Downloads page on OTN.  If you have Application Express 4.2 or 4.2.1 already installed, then you need to download the APEX 4.2.2 patch set from My Oracle Support.  Look up patch number 16277995.

As is stated in the patch set note that accompanies the Oracle Application Express 4.2.2 patch set:

• If you have Oracle Application Express release 4.2 or 4.2.1 installed, download the Oracle Application Express 4.2.2 patch set from My Oracle Support and apply it.  Remember - patch number 16277995.
• If you have Oracle Application Express release 4.1.1 or earlier installed (including Oracle HTML DB release 1.5), download and install the entire Oracle Application Express 4.2.2 release from the Oracle Technology Network (OTN).
• If you do not have Oracle Application Express installed, download and install the entire Oracle Application Express 4.2.2 release from the Oracle Technology Network (OTN).

As usual, there are a large number of issues corrected in the Application Express 4.2.2 patch set.  You can see the full list in the patch set note.

Like all patch sets for Oracle Application Express, there are a large number of functional issues corrected in this release.  But also with the APEX 4.2.2 patch set are a large number of updates to the packaged applications - improved user interface, improved layout and functionality, improved accessibility, improved security, and a fair number of functional bugs corrected.  Also in APEX 4.2.2 is a new often-requested application called Survey Builder.  This application was architected by John Snyders, who did a masterful job in its creation.  I truly think Survey Builder has the potential to be a "killer" APEX application.

The Great Lakes Oracle Conference will be held on May 14/15, 2013 at the Cleveland State University campus.  Registration includes two full days of training with more than 30 sessions to choose from, vendor exhibits to peruse, lunches, and a networking reception.  And if that weren't enough, there will be keynote presentations from Chris Date and Tom Kyte.

There are actually three pre-conference workshops (at additional nominal cost) on three totally distinct topics - All About Binding from Tom Kyte, Oracle Performance Research Seminar from Craig Shallahamer, and Oracle Application Express - I Never Knew It Was So Easy! from me.  If you've wanted to get your feet wet with Oracle Application Express, this may be the workshop for you - completely hands on - building, tuning, debugging and monitoring APEX applications.  This is geared toward the beginner/intermediate developer - no knowledge of APEX is assumed.

I reviewed the list of presentations and presenters, and I'm convinced this is one of the highest quality events available in the Midwest (U.S.).  The early registration rate for the conference is $250 until April 12.

Most people are aware of apex.oracle.com, the demonstration instance of Oracle Application Express.  It's primarily used for people to "kick the tires" of APEX.  Last week alone, there were 810 new workspaces approved on this instance.

Changes are coming to apex.oracle.com - it's going to be consolidated onto other hardware and also Oracle Database Vault will be installed and implemented.  Part of the process of installing Oracle Database Vault includes running the script $ORACLE_HOME/rdbms/admin/utlrp.sql.  This script will attempt to recompile all invalid objects in the database.

As of today, 08-MAR-2013, there are 62,197 invalid database objects across all of the workspaces on apex.oracle.com - not that bad, considering there are 17,447 APEX workspaces and 17,984 workspace schemas.  However, it takes a long time to attempt to recompile 62,197 invalid database objects.  And this will only serve to dramatically increase the outage time for this instance.

Thus:

1. A listing of all invalid database objects in the workspace schemas was computed today, 08-MAR-2013.
2. A second listing of all invalid database objects in the workspace schemas will be computed again on 13-MAR-2013.
3. All invalid objects contained in both reports will be immediately dropped with no chance of recovery (as the Recycle Bin will be purged).

Update March 12, 2013:  This drop and purge will no longer occur on 13-MAR-2013, nor at any time in the future.  We were able to make significant progress in the reduction in the number of invalid objects (reduced by 85%).  Thus, we're going to live with the additional outage time cause by this recompilation instead of dropping objects in workspace schemas.