Skip to main content

UKOUG 2008 Report Back

This year I decided to do just one post about the UKOUG and not - as previous year - (try to) get out a post every day. Takes the pressure of me...
The first impression is that Birmingham was quite cold this time of year, the second is that the UKOUG seems less crowded this year. The first observation is quite right, the second one is wrong. Due to the shifted schedule of the session, they not all start and end at the same time, so the crowd is more scattered over the day. So no long lines for the food or traffic jams in the Exhibition Hall (the fact was that there where about 2,250 attendees, 'just' 5% less than next year - probably to do with the financial situation out there).
I won't list all the sessions I went to: See the previous post about my intentions - I didn't made all of them...

My personal top 3 this year (in order of appearance):

Beginners' Guide To Trouble-shooting
by Jonathan Lewis
I had never seen Jonathan presenting before but it is good to get an introduction into this subject by the master himself. He split up the performance in a quadrant with 'Wait Time' and 'Service' on one side and 'Using' and 'Competing' on the other side. That gives an insight where to look for one of the three classifications of problems : 'My task is slow', 'The batch took too long', 'The system is slow'.

Oracle SQL Developer: Focusing on a Few Advanced Features by Sue Harper
Sue showed how to create and use XML extensions, remote debugging APEX applications and how to Refactor anonymous PL/SQL blocks in APEX into database procedures. If she had the time she could have shown a lot more than she did, but (just like in a lot of other sessions) 45 minutes is very very short....

Performance Tuning Basics by Doug Burns
Doug did a great job in big Hall 1. His presentation ran very smoothly as well as in presentation style, in the sheets (just a few words or a picture on every sheet) as in content. He explained about ASH, AWR and ADDM - acronyms I had heard about but didn't quite understand the details (as I am not a DBA - apparently). The main message was: The only thing that really matters in the end is: DB Time, not latches, buffer gets, reads etc - only the time that passes between a user action and a system response defines the performance (but of course all the reads and latches and stuff lead to a certain DB Time...).

My own session:
On the last full day of the conference around 03:00 PM I had my session. It was a rather small room, with around 100 seats but pretty well attended with an audience of around 80 people. IMHO all went very good, ended right on time and could even answer some questions. My goal was to show that you can do a lot more with APEX than what is widely known and I think I got that message across. I did a sneak peek at the evaluation forms and saw a lot of 'Excellents' and 'Very goods' and some very positive comments. So I was (and still am) quite happy about that! BTW I already uploaded the application to apex.oracle.com, but I still have to seed it with some data. If that is finished I'll post the link on this blog.
Because there wasn't that much APEX going on, I 'had' to visit sessions with other interests, like performance tuning and JDev. I don't know yet if that's a good or a bad thing. But I will sure to try to get in (again as a presenter) next year! BTW next year the UKOUG will split the different streams into different shorter events. The (to me) most interesting event will still be at the end of November, but then only for three days.
7 comments

Popular posts from this blog

Refresh selected row(s) in an Interactive Grid

In my previous post I blogged about pushing changed rows from the dabatase into an Interactive Grid. The use case I'll cover right here is probably more common - and therefore more useful!

Until we had the IG, we showed the data in a report (Interactive or Classic). Changes to the data where made by popping up a form page, making changes, saving and refreshing the report upon closing the dialog. Or by clicking an icon / button / link in your report that makes some changes to the data (like changing a status) and ... refresh the report.  That all works fine, but the downsides are: The whole dataset is returned from the server to the client - again and again. And if your pagination size is large, that does lead to more and more network traffic, more interpretation by the browser and more waiting time for the end user.The "current record" might be out of focus after the refresh, especially by larger pagination sizes, as the first rows will be shown. Or (even worse) while you…

Dockerize your APEX development environment

Nowadays Docker is everywhere. It is one of the main components of Continuous Integration / Continuous Development environments. That alone indicates Docker has to be seen more as a Software Delivery Platform than as a replacement of a virtual machine.

However ...

If you are running an Oracle database using Docker on your local machine to develop some APEX application, you will probably not move that container is a whole to test and production environments. Because in that case you would not only deliver a new APEX application to the production environment - which is a good thing - but also overwrite the data in production with the data from your development environment. And that won't make your users very excited.
So in this set up you will be using Docker as a replacement of a Virtual Machine and not as a Delivery Platform.
And that's exactly the way Martin is using it as he described in this recent blog post. It is an ideal way to get up and running with an Oracle database …

apex_application.g_f0x array processing in Oracle 12

If you created your own "updatable reports" or your custom version of tabular forms in Oracle Application Express, you'll end up with a query that looks similar to this one:
then you disable the "Escape special characters" property and the result is an updatable multirecord form.
That was easy, right? But now we need to process the changes in the Ename column when the form is submitted, but only if the checkbox is checked. All the columns are submitted as separated arrays, named apex_application.g_f0x - where the "x" is the value of the "p_idx" parameter you specified in the apex_item calls. So we have apex_application.g_f01, g_f02 and g_f03. But then you discover APEX has the oddity that the "checkbox" array only contains values for the checked rows. Thus if you just check "Jones", the length of g_f02 is 1 and it contains only the empno of Jones - while the other two arrays will contain all (14) rows. So for processing y…