x int default s.nextval primary key

How cool is that?

No longer will you need to create a trigger to fill the column with the nextvalue from a sequence, you just declare it this way and you’re done.

Maybe it’s just syntactic sugar, I don’t know (yet) and frankly I don’t care. I like the fact that this feature makes it more declarative to populate the primary key (or any other column of course).


I’m happy.

• Improved PL/SQL and SQL interoperability

  In the current version of the Oracle database you needed a Nested Table or Varray Type defined at schema level in order to be able to use it in the TABLE operator.
  This is no longer necessary, it can be a PL/SQL declared type.
  
  The types that can be used as bind variables has been extended: Boolean, Nested Tables can be used as bindvariable in Dynamic SQL.
  
  Subquery Factoring (the With clause if you will) can hold private functions, the use case presented for this: pretty print an integer in K, M, G, T.
  
  Using userdefined PL/SQL functions in a SQL statement is not advisable, but if you really need to there is a new pragma: PRAGMA UDF. With this pragma the statement is almost as fast as pure SQL.
  

• Security

  A new step has been taken to continue on “least privileges”, meaning that the user only gets the privileges that are absolutely necessary. A Role can be granted to a PL/SQL unit.

• Improved programmer usability

  The ability to inspecting the callstack has been improved by the introduction of a new package: UTL_CALL_STACK. The package contains numerous functions to help in this area, such as current_edition and lexical_depth.
  White listing of program units: restrict which program unit can be called by other program units.

So, is PL/SQL still alive? YES! ALIVE AND KICKING!

On a side note:
Just before landing in San Francisco there was an announcement: “Place your chair in the upright, most uncomfortable position”. I thought it was funny, seems like I was the only one noticing it though. You get people staring at you when you start to laugh without apparent reason.

Aangezien niet iedereen in de gelegenheid is om naar Las Vegas te gaan voor het bijwonen van deze conferentien, wordt er door Inter Access een Dutch Preview Event georganiseerd. En wel op woensdag 18 april vanaf 17 uur op ons kantoor te Hilversum, waar alle presentaties van deze experts zullen worden getoond. Van Application Development, E-Business Suite Security, SOA tot Oracle Fusion Applications, de onderwerpen zijn zo divers dat je zeker een interessante avond zult beleven.

Aanmelden voor deze preview kan per mail naar info@interaccess.nl.
Meer informatie is verkrijgbaar via Arnoud Roth, bereikbaar op telefoonnummer: 06-54363429

De sprekers en hun onderwerpen:

Alex Nuijten, AMIS

• Solving Puzzles with SQL: Cheating when playing the game SET
• Who’s Afraid of Analytic Functions
• Database Development: SQL Holmes – The Case of the Missing Performance

Roel Hartman, Logica

• 5 Cool Things You Can Do With HTML5
• APEX Boot Camp: Striving for Perfection: The Ultimate APEX Architecture
• Done in 60 Seconds – Creating Web 2.0 Applications Made Easy

Arian Stijf, Arven

• Securing the E-Business Suite. A Layered Approach
• From Workflow to BPEL

Arnoud Roth, Inter Access

• Oracle Fusion Applications Architecture Fundamentals

Toon je interesse hier: Linked-in event

Alex

On the Sunday before the actual conference starts, the OakTable organized a special day. Originally I didn’t plan to attending this day, as I was flying in in the afternoon. Turned out, I was on time to attend Connor McDonald’s session. Lucky me, Connor is an awesome presenter, so I decided to stay for the rest of the day. Very enjoyable, they even had OakTable beer before the final OakTable panel session.
In the evening there was the Ace dinner, in a nearby Thai restaurant. Good company, good food. A little nerdy perhaps, but as it turned out there were 42 Ace’s and Ace Directors attending.
On Monday I attended some really good sessions, like Kyle Hailey on SQL Tuning, Bryn Llewellyn on Using the PL/SQL Hierarchical Performance Profiler, and Connor McDonald on Partitioning 101.
Late in the evening Cary Millsap did a keynote session: Learning about Life through Business and Software. Only one word for this session: Wow! The things he talked about are still going around in my mind.
Tuesday morning, right after Roel Hartman’s session Done in 60 seconds, was my own session Who’s afraid of Analytic Functions? – for which I was quite nervous. Got some nice feedback on the session, so was quite pleased with it. Of course I had to go and see Carl Dudley’s session on Analysing Your Data with Analytic Functions – check out the competition, so to speak. Michael Salt’s session on Indexing: It’s All In The Index was also very interesting.
Wednesday was time to head back home, so packed up my bags and went to see Jonathan Lewis’ session on Redo. Can you keep an audience captivated for an hour talking about Redo? Jonathan Lewis can. Sadly this was my last session.
Because I arrived early at the Birmingham International Airport, I could get an earlier -originally delayed- flight back to The Netherlands. Now I can look back at a wonderful conference….
Oh,… did I mention I received the Inspiring Presentation Award for my session I did last year?

For this example we are going to use a “Report with Form” and modify it as described below.

All of our pages in the application have a page alias, the Report page alias is “EMP001″ and the Form page has an alias “EMP002″.
The default behaviour will appear in the page like the below screenshot, the cursor will turn into a small hand only when you move your mouse over the icon.

But we want to achieve the following: moving the cursor over the whole row changes the cursor to a small hand  indicating that the whole row is clickable. And not only that, also that the whole row is in fact clickable.

To achieve this we would need to “move” (or copy) the anchor to row-level.

When you look at the generated HTML code, it will look something similar to this:

The highlighted line in the picture is the icon which is shown in the Report page (alias: EMP001). As you can see in the image, the anchor (the “a” tag) has an href attribute which contains all the information it needs to navigate to the Form page (alias: EMP002). Even the page alias is in there, and this is what we will use to select the correct href.

Because the page alias is in the anchor, we can use the jQuery selector to get the appropriate element

$('a[href*="EMP002"]')

This will result in an array of anchor elements which we want to manipulate. For each of the elements in the array we want to retrieve the href attribute. The href attribute, we will keep in a local variable named “lnk”. Now the code will look like:

$('a[href*="EMP002"]').each(function(index) { 
    lnk = $(this).attr('href');

});

This variable with the href attribute is going to be place at row level as a “data-href”. From the current element we need to move up to the row level (tr) and add the attribute.

   $(this).parent()
          .parent('tr')
		  .attr('data-href', lnk)

To make it clickable, we also need to add a click event to the row. This is where jQuery really shows its power, we can “chain” the click event to our selector. The code will grow slightly to the following:

 $(this).parent()
          .parent('tr')
		  .attr('data-href', lnk)
		  .click(function(){
		    window.location=$(this).attr('data-href');
		  })

To give the user the feedback that the row is clickable, we need to change the cursor to a little hand. Again we chain the mouseover event to the selector

$(this).parent()
          .parent('tr')
		  .attr('data-href', lnk)
		  .click(function(){
		    window.location=$(this).attr('data-href');
		  })
		  .mouseover(function(){
		    $(this).css('cursor', 'pointer');
		  })

And because we also want to change the cursor back to default when the user move the cursor away from the rows in the report, the mouseleave event is also required

   $(this).parent()
          .parent('tr')
		  .attr('data-href', lnk)
		  .click(function(){
		    window.location=$(this).attr('data-href');
		  })
		  .mouseover(function(){
		    $(this).css('cursor', 'pointer');
		  })
		  .mouseleave(function(){
		    $(this).css('cursor', 'default');
		  })

When you run the page you will notice that the whole row is clickable.

Inspecting the HTML after we add all the jQuery code will show that there is an anchor at the row level now, just what we wanted.

To make copy the code for your own use, the completed jQuery code will look like this

$('a[href*="EMP002"]').each(function(index) {
   lnk = $(this).attr('href');
   $(this).parent()
          .parent('tr')
		  .attr('data-href', lnk)
		  .click(function(){
		    window.location=$(this).attr('data-href');
		  })
		  .mouseover(function(){
		    $(this).css('cursor', 'pointer');
		  })
		  .mouseleave(function(){
		    $(this).css('cursor', 'default');
		  })
});

And to see this in action you can find a demo on apex.oracle.com

When creating an editioning view, I believed it was “required” to name the columns in your view instead of using the wildcard “*” to select the columns. Shielding the editioning view from table alterations. So let’s start with an edition enabled user to setup our table.

SQL> conn alex/alex@xe11
Connected.
SQL> alter user alex enable editions
  2  /

User altered.

SQL> select *
  2    from v$version
  3  /

BANNER
---------------------------------------------------------------------
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for 32-bit Windows: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

5 rows selected.

SQL> create table "_EMP"
  2  (empno number
  3  ,ename varchar2(20)
  4  )
  5  /

Table created.

As you can see in the above code snippet, I run this test on Oracle Database 11g Express Edition. The tablename I picked up from Connor’s session. Naming your table something freakish will (hopefully) stop developers from using the table directly in their code. I like that naming convention. Let’s continue with two editions

SQL> create edition r1 as child of ora$base
  2  /

Edition created.

SQL>
SQL> create edition r2 as child of r1
  2  /

Edition created.

In each of the editions we will create an editioning view using the wildcard “*” to select the columns

SQL> alter session set edition = r1
  2  /

Session altered.

SQL> create or replace
  2  editioning view emp
  3  as
  4  select *
  5    from "_EMP"
  6  /

View created.

SQL>
SQL> alter session set edition = r2
  2  /

Session altered.

SQL> create or replace
  2  editioning view emp
  3  as
  4  select *
  5    from "_EMP"
  6  /

View created.

SQL>

I believed, wrongly, that the wildcard “*” would be dynamic, meaning that if the table definition would change both editioning view would include the new column as well. This is not the case.The editioning views don’t even get invalidated…

SQL> alter session set edition = ora$base
  2  /

Session altered.

SQL> alter table "_EMP"
  2  add something varchar2(10)
  3  /

Table altered.

SQL> select owner
  2       , object_name
  3      , status
  4    from all_objects_ae
  5   where object_name = 'EMP'
  6  /

OWNER                          OBJECT_NAME                    STATUS
------------------------------ ------------------------------ -------
ALEX                           EMP                            VALID
ALEX                           EMP                            VALID

2 rows selected.

Even though they don’t get invalidated, the definition of the editioning views surely must be changed then….

SQL>
SQL> alter session set edition = r1
  2  /

Session altered.

SQL> desc emp
 Name                                                              Null?    Type
 ----------------------------------------------------------------- -------- ----------------------

 EMPNO                                                                      NUMBER
 ENAME                                                                      VARCHAR2(20)

SQL>
SQL> alter session set edition =  r2
  2  /

Session altered.

SQL> desc emp
 Name                                                              Null?    Type
 ----------------------------------------------------------------- -------- ----------------------

 EMPNO                                                                      NUMBER
 ENAME                                                                      VARCHAR2(20)

SQL>

No. The definition includes the columns which existed before we altered the table.
What is stored in the metadata, you may wonder. Let’s go and find out:

SQL> alter session set edition = r1
  2  /

Session altered.

SQL> set long 50000
SQL> select dbms_metadata.get_ddl ('VIEW'
  2                               ,'EMP'
  3                                                      )
  4    from dual
  5  /

DBMS_METADATA.GET_DDL('VIEW','EMP')
--------------------------------------------------------------------------------

  CREATE OR REPLACE FORCE EDITIONING VIEW "ALEX"."EMP" ("EMPNO", "ENAME") AS
  select "EMPNO","ENAME"
  from "_EMP"


1 row selected.

SQL>
SQL> alter session set edition =  r2
  2  /

Session altered.

SQL> select dbms_metadata.get_ddl ('VIEW'
  2                               ,'EMP'
  3                                                      )
  4    from dual
  5  /

DBMS_METADATA.GET_DDL('VIEW','EMP')
--------------------------------------------------------------------------------

  CREATE OR REPLACE FORCE EDITIONING VIEW "ALEX"."EMP" ("EMPNO", "ENAME") AS
  select "EMPNO","ENAME"
  from "_EMP"


1 row selected.

As you can see in the output above, the actual column names are in the metadata, shielding changes to the editioning views when the table definition changes.
Connor was absolutely right about the mechanics of Edition Based Redefinition. Does this mean you should use the wildcard “*”in your editioning views? I believe not, I believe you should explicitly name the columns that you want to include in a specific edition. This way it is more clear to the developers, and DBA alike. Rerunning the scripts might all of sudden include columns in an edition which weren’t suppose to be there. When you explicitly name your columns, you won’t have this problem.

Just the last bit, cleaning up my environment:

SQL> alter session set edition = ora$base
  2  /

Session altered.

SQL> drop edition r2 cascade
  2  /

Edition dropped.

SQL> drop edition r1 cascade
  2  /

Edition dropped.

SQL> drop table "_EMP" purge
  2  /

Table dropped.