A question often asked by users, is the addition of tooltips with extended functions (like line breaks or formatting) to Application Express. There is no default functionality in Apex for that, other than the standard alt or title tag in HTML, which I think is rather boring.
There is a more versatile and nice looking alternative for that, called qTip2. It’s an extension for JQuery, which is already incorporated in Apex since version 4.0.
I found it a little challenging to get qTip2 working in Apex, so here’s a how-to for you.
- go to the Edit Page section and add this to the HTML Header Atribute :
<link type="text/css" rel="stylesheet" href="#WORKSPACE_IMAGES#jquery.qtip-2.0.0.css" />
- Add this to the Footer Text Attribute a little lower:
- And add this code to the Function and Global Variable Declaration. It replaces the standard title attributes with the qTip attribute. Mind you: alltitle attributes on the page. That’s ok, it ensures a consistent look of your tooltips on the page.
- Now let’s give it a try. Create a new Text item on your page, and put this in the Label attribute:
<a href="#" title="Your <i>custom</i> label Tooltip">A tooltip label</a>
- And look at the result:
Of course you can also use the syntax used in step 7 in other parts of your page, like report headers, poplists or just plain text.
Something I’ve posted before…. but I thought it was time to rewrite it a little.
We all are at least a bit aware of the awkward behaviour of NULL in Oracle. But it still is difficult every time we encounter it in a function or where-clause.
Some examples to keep in mind when comparing NULL values:
1. null equals what?
Null equals nothing, in fact. It doesn’t even equals to itself.
And because of that, a condition does not always behave in the way you would expect.
Let’s start straightforward.
a := 10 a is null results in FALSE a is not null results in TRUE
a := null a is null results in TRUE a is not null results in FALSE
We’ve all been there, done that and got ourselves the t-shirt.
a := null b := null
This is a situation that you’re bound to encounter sooner or later. Both a and b are null. Let’s compare it!
select 'x' from dual where a = b;
What is the result? FALSE?
Wrong! But it’s certainly not TRUE either. This expression results to UNKNOWN. And that state is a very dangerous one to be in!
Because UNKNOWN acts very similar to FALSE you might be tricked in thinking that they always behave the same. And that is not true. When a condition evaluates to UNKNOWN, no rows will be returned. In that sense it is similar. But look at this:
SQL> create table nulls( id number(9), value1 varchar2(20)); Table created. SQL> insert into nulls values ( 1, 'A collection of '); 1 row created. SQL> insert into nulls values( 2, null ); 1 row created. SQL> insert into nulls values( 3, 'something else'); 1 row created. SQL> select id 2 from nulls 3 where value1 = 'A collection of ' 4 /
ID ---------- 1
That is exactly what we expected. “Where value1 = ‘A coll…’ ” evaluates to TRUE, so a row is returned, and “Where value1 = null” evaluates to UNKNOWN. No row is returned.
Finally, “Where value1 = ’something else’ “, evaluates to FALSE and no row is returned. All expected behaviour.
SQL> select id from nulls where NOT( value1 = 'A collection of '); ID ---------- 3
If we place a NOT operator around the conditions, the difference becomes clear. TRUE has become FALSE, FALSE has become TRUE, and UNKNOWN… is still UNKNOWN. And hence row 2 is not displayed.
2. Nulls in indexes
I’ve created a table with one varchar2 column and 5000 records. The column contains a normal B-Tree index (tst1) and a function based-index tst2 (with function “where NVL( value1, ‘|empty|’ )”. One record is NULL, and unfortunately, that is exactly the one I am looking for. How does this affect performance?
SQL> select count(*) from psi_test where value1 is null; 1 row selected. Execution plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=11) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'PSI_TEST' (TABLE) (Cost=11 Card=509 Bytes=5599) SQL> select count(*) from psi_test where nvl(value1, '|empty|') = '|empty|'; 1 row selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=11) 1 0 SORT (AGGREGATE) 2 1 INDEX (RANGE SCAN) OF 'TST2' (INDEX) (Cost=2 Card=510 Bytes=5610)
As you see, the optimizer does a full table scan on the first example, and an index range scan on the second. Of course, this is a very basic example, but it explains the idea.
3. null functions
NVL is well-known, it’s been there for ages. The function NVL returns the value of its second argument if its first argument is null.
SQL> select value1, nvl( value1, '!! NULL values....' ) from nulls; VALUE1 NVL(VALUE1,'NULLVALU -------------------- -------------------- A collection of A collection of !! NULL values.... something else something else
Powerful, very convenient, so often used.
And what if you want to determine the returned value based on whether an expression is null or not null? NVL is not so useful for that. But NVL2 is. NVL2 has not two but three arguments. The first is the tested value. If that is not null, the second expression is returned. If it’s null, the third expression is returned.
SQL> select id , nvl2( value1 , 'this column is not null' , 'and this columns is NULL' ) test from nulls; ID TEST ---------- ------------------------ 1 this column is not null 2 and this columns is NULL 3 this column is not null
I think these little examples cover most of the issues you can encounter with null values. Don’t get tricked by a null!