Oracle Application Express 4.1 released

Data Upload - add functionality to your application so your end users can upload CSV data (similar to what you can use in Application Express SQL Workshop)

Error Handling - Dramatically improved error handling, where you can define how exceptions are handled in your application instead of being constrained by the APEX engine itself. Patrick discussed this in detail here and here.

ROWID - Instead of being constrained by one or two element primary keys, you can simply use ROWID as the unique identifier for Automatic DML forms and tabular forms.

Websheets - Websheets have undergone a complete overhaul of the user interface, as well as some interesting new features, like the ability to create reports on SQL queries against DataGrid data.

Tabular Forms - Many new features with tabular forms, including tabular forms processes and tabular form validations.

Plug-Ins - Support for Authentication and Authorization plug-ins

Calendars - Enable editing of data directly from links in a calendar, and also support drag-and-drop to move rows from one day/time to another.

Dynamic Actions - Support added for dynamic actions against buttons, and other enhancements.

Accessibility - Numerous accessibility improvements have been made in the templates and HTML produced by Application Express.

One obvious question is going to be "where is mobile support?" When jQuery Mobile becomes production software, we will include it in the very next patch set of Oracle Application Express. The infrastructure is there in APEX 4.1 to support it. And Marc Sewtz has promised to blog about how you can drop in the jQuery Mobile Beta into an APEX 4.1 installation. The jQuery Mobile Beta portion can't be supported by Oracle Support, obviously.

Our many thanks to the countless people who participated in the Application Express 4.1 Early Adopter program and provided feedback, suggestions and bug reports. We also owe a special thanks to the many Oracle employees who run their mission critical applications on apex.oraclecorp.com (an internal instance of Application Express, but for production applications, used by virtually every business unit in the company). They reported many issues and endured some outages while we rectified flaws in the upgrade process and Application Express engine itself. It is thanks to their patience and problem reporting that we were able to avoid embarrassing and reputation-breaking occasions for our customers.

After upgrading to 4.1, export application fails with "Error exporting flow 103. ORA-06502: PL/SQL: numeric or value error: character string buffer too small", only if setting "export translations" to yes. I could not find anything about this on metalink or google. Any suggestions?

querying WWV_FLOW_TRANSLATABLE_TEXT$ helped to find "large" translation units. It was a region source with more than 7k length (a rather large select I would say). Deleting the region and re-seeding made the export problem go away. I think this maybe considered a bug by some - at least it should be mentioned in Apex limits.

still struggling with importing application exported with translations. Two things:1.the import creates the mapping but it can choose a translated application id ending with zero, which could cause a possible conflict in the decimal part of ids of translations2.the imported translations in WWV_FLOW_TRANSLATABLE_TEXT$ retain the decimal part of the original mapping (the integer part is changed OK) so publishing the newly imported app won't use the imported translations although they can be seen in the manual edit of translation repository. For example let's say that I have an app with app_id 123 in primary lang 'de' and there's a mapping with app_id 1231 in 'en'. Export this with translations and import it back again to a different app_id. Let's say the new app_id is 543 and the mapping id (chosen automatically) is 131. Then

Thank you for reporting these issues. These are actually two distinct problems within the translation process.

The issue with a translatable element greater than 4K is a complete blunder. This is logged as Bug 12927199 and will be fixed in the 4.1.1 patch set.

Also, the issue with the incorrect decimal portion of the translatable text ID after import is filed as Bug 12927540 and will also be fixed in the 4.1.1 patch set too. I believe an easy workaround to remedy this would be to edit and modify the translation mapping ID within Application Builder Shared Components.

Due to the egregious nature of both of these bugs, I have uploaded patch set exceptions ("one-off patches") for both of these to My Oracle Support. These can be applied to a 4.1.0.00.32 instance. You should be able to locate them by the bug number.

Thanks again for reporting these bugs and sorry for the issues created by these problems.

Joel,I'm really sorry but it seems that when I change the translation application id on the "Application Language Mapping" page, the decimal portion of translate_to_ids in WWV_FLOW_TRANSLATABLE_TEXT$ does not change (translated_flow_id is updated correctly). I have not applied your patch yet.

About Me

My name is Joel Kallman. I am the Director of Software Development at Oracle, and I manage the development and product management of Application Express (APEX) at Oracle. I've been at Oracle since 1996, and my VP Mike Hichwa and I created Application Express in 1999. My passion is to make customers extraordinarily successful with the Oracle Database, PL/SQL and Oracle Application Express.