APEXblog.nl - Tips and Tricks

About This Blog:
I (Richard Weug) started this blog primary for myself to save all kinds of Apex tips and tricks in one place. To use it as a place to write down how I used some coding in my own projects, but also to copy and paste all kinds of articles I find on the Internet. (So I never have to wonder on what website did I read about??? When I see something interesting I collect the content so I have my own archive/knowlegde base.

View my profile on LinkedIn




Recognize your APEX dev, qa and prod environments

Written by Richard Weug on Tuesday, 25 March 2014 14:35. Posted in Tips and Tricks

Here is a very quick entry, mostly to document how I sometimes keep applications in dev and QA (or prod) apart.  Lately I’ve been working with development and QA applications that live in the same workspace and server. Dev would be in one schema and QA in a different one.  Sometimes it’s a little too easy to make a mistake. This simple technique helps me keep my sanity.

In dev I have a watermark that says development. The image below repeats all over the background.  Click here to download.


development.png Right click to save.

// this is for DEV only, and will set a "development" background image
$("body").css("background-image", 'url(wwv_flow_file_mgr.get_file?p_security_group_id=2246505718948672&p_fname=development.png)');
$("#container").css("background-image", 'url(wwv_flow_file_mgr.get_file?p_security_group_id=2246505718948672&p_fname=development.png)');

In qa or prod I make sure the developer toolbar is red.

 // this is for Developers only to make sure we know we're in QA/prod 
 $(function() { $("#apex-dev-toolbar").css("background-color", 'red'); });

How to use it?

The development.png image goes in the workspace images, available to all apps.  I like to place either snippet in the “Global Notification” field for the app.

Global Notification

Why there? I like being able to edit or remove this code from the application without actually changing the app. Plus it’s automatically added to all pages.  When you promote from QA to prod you could actually leave the snippet that changes the toolbar in place since it will only be displayed to developers that log in to the builder.

The end result with the watermark looks like this:

Development Environment

Development Environment

I like that the development image will show up for everybody using the application, not just developers. It also helps when a user forgets or doesn’t realize which system they are using.

The end result for the developer toolbar looks like this:

APEX Developer Toolbar in red

APEX Developer Toolbar in red

Final Note

The selectors for the development image may need to be adjusted to your application. ALL application will have the body tag, that one doesn’t need to change.  However, we will often have too much content on top of it to see the watermark.  That’s why I also add it to the #container  The #container id will work fine for Theme 26 (and other themes).  For Theme 25 you may want to change from #container to #uBodyContainer  Sometimes you’ll need to experiment a little.

The red toolbar technique will also work on APEX 5, but instead of #apex-dev-toolbar use #apexDevToolbar

APEX 5 dev toolbar

APEX 5 (EA) dev toolbar


Execute PL/SQL in background

Written by Richard Weug on Sunday, 23 March 2014 16:09. Posted in Tips and Tricks

PL/SQL Logik in APEX zu platzieren ist etwas völlig Normales und findet nahezu überall täglich statt. Gelegentlich kommt es aber vor, dass aus APEX heraus solche PL/SQL-Logik angestoßen werden soll, die länger laufen wird. Hinterlegt man diese ganz normal als PL/SQL-Prozess im onLoad oder onSubmit-Bereich, so müsste der Anwender mit dem Browser solange warten, bis der Prozess durchgelaufen ist. Das kann für eine bis zwei Minuten noch eben akzeptabel sein (ein Hinweis ist unbedingt nötig), dauert es aber länger, so muss der PL/SQL-Prozess in den Hintergrund gebracht werden.


Referencing USER in APEX

Written by Richard Weug on Wednesday, 05 March 2014 16:00. Posted in Tips and Tricks

It’s not uncommon to reference the current user as USER in your pl/sql code. A simple use case may be to determine the client or environment that you’re running in (ex: dev, test, prod).

Referencing USER will have some slight side effects when running the code in APEX as the current USER is actually APEX_PUBLIC_USER (or what ever user you configured). This can cause issues in your application. To resolve it, simply reference sys_context('userenv','current_schema’) instead.


Public Check Authorization

Written by Richard Weug on Tuesday, 04 March 2014 16:03. Posted in Tips and Tricks

APEX Authorization Schemes are a very effective and simple way to restrict elements in our applications.  Once defined, these authorizations can be applied to the majority of elements in APEX: Pages, Regions, Items, Buttons, Processes, Branches, etc…

There are several ways to code them, it will depend on your needs, but ultimately they return TRUE or FALSE.  Is the user ADMIN or NOT ADMIN.  Say for example that we have a MYAPP_USER_ROLES table that stores ROLE_KEY and USERNAME columns. In this case, we could define an “ADMIN” Authorization Scheme of type “Exists SQL Query” that looks like this:


Don’t (always) call v()

Written by Richard Weug on Monday, 24 February 2014 16:13. Posted in Tips and Tricks

Instead of calling a function, when you can get the same effect by accessing a documented PL/SQL variable, you should. For example:

v('REQUEST')     = APEX_APPLICATION.g_request
v('APP_ID')      = APEX_APPLICATION.g_flow_id
v('APP_PAGE_ID') = APEX_APPLICATION.g_flow_step_id
v('DEBUG')       = APEX_APPLICATION.g_debug