Duncan Mein's Blog

If you have an HTML page containing only 1 Textbox, standard HTML / browser behavior is to allow the page to be submitted when entered is pressed. Normally I don't have an issue with this but in APEX, no request value is picked up when the page is submitted this way. Consequently, you usually get an error implying there is no page to branch to as the page was submitted without a request value. The solution to this problem is very simple. Create a dummy textbox on the page and in the: HTML Form Element Attributes attribute, enter the following: style="display:none;" Now because the browser thinks 2 textboxes exist, page submission by pressing enter will not occur. Simple solution to a small but annoying problem

If like me you have written several PL/SQL procedures within your APEX app, you will have had to deal with the issue of error handling. As a general rule, I try to hide all Oracle Error Messages from the user and replace these with something more meaningful for example: If a user breaks a unique key by trying to insert the same value twice, the following error message is not uncommon: ORA-00001 Unique constraint violated There is little or no merit rendering this message to a user as those outside the Oracle community, may not be able to deduce what went wrong. We can capture this error and translate it to a user friendly message explaining what went wrong for example: The record you tried to create already exists. Please try again In order to achieve this in APEX, the process is relativly simple. Set up your Custom Error Page 1. Create a new page with the following attributes: Page type: Blank Page Page Number: your choice (for this example I used page 500) Page Alias: ERRPAGE Name:...

In a recent application, we needed to model the Organisational Hierarchy which at its most complex ran to 7 levels deep. This was achieved using a self referencing foreign key (Pigs Ear) similar to that of the EMP table in the Scott schema. In essence, it simply stores the parent / child relationship for each entry in the Hierarchy. This approach serviced the application very well in that a simply tree walk (CONNECT BY PRIOR) allowed us to construct the Hierarchical tree and bounce our requests off that. During the production of the Discoverer End User Layer, it became evident that this Hierarchy needed to be flattened out (un-normalized) in order for it to reported on. This is because Discoverer (or any other BI product) does not support the CONNECT BY and START WITH clause. Discoverer needs to know how many levels exist within a Hierarchy and that every thread in the Hierarchy has the same number of levels in order to build a folder structure that can be reported on. After a bit of i...

It has always been a fairly rudimentary task pivoting a result set so that rows are displayed as columns. More recently I had the requirement to translate a result set the other way so that the columns would be displayed as rows. For Example Your result set starts out like this: SITE COST1 COST2 COST3 COST4 ------------------------------------------------------------------ SITE_ONE 2000 255 SITE_TWO 100 SITE_THREE 145 5000 The desired output should look like this: SITE VALUE ------------------------------ SITE_ONE 2000 SITE_ONE 255 SITE_TWO 100 SITE_THREE 145 SITE_THREE 5000 Thanks to the help from Mr. Tom Kyte at http://asktom.oracle.com I was a...

When your PL/SQL block errors, it has always been a rudimentary task in identifying the error generated using a combination of SQLCODE and SQLERRM. These 2 functions however do not tell us the exact line of code that propagated the error. This feature would be very handy when debugging code. In Oracle 10g, there is a function called: DBMS_UTILITY.format_error_backtrace This will return the line number that generated the error. It does not tell us what the SQL Error message is so I use it in conjunction with SQLERRM to quickly debug problematic code. In a recent application, I used it as part of my error logging and reporting function that allows the support team to quickly troubleshoot errors. The more information about the error we can give them, the quicker they should be able to response. At least that’s the theory. For a more detailed explanation of how to best utilise this function, have a look at this atricle

Well, our week skiing in Meribel came and went too quickly. We all had am awesome time in the "Best British Ski Resort" France has to offer. The Skiing was good (not excellent) but enough to thoroughly exhaust every one of us and our Chalet was very comfortable. Living costs in the Trois Valleys was not cheap however. Beer ranged between 8 and 10 Euros a pint which made for some very expensive nights out. Fortunately, food was included in our Chalet costs. I was devastated parting with 40 Euros for a lasagne, chips and a coke in Courcheval but hey. For anyone interested, some pictures can be found here I shall be putting them all on my website in the next few weeks.

For anyone who has manually written an Update Statement in a Web Application, the issue of Optimistic Locking always took a while to address. The normal convention is to use a series of hidden elements for every form element that is submitted and doing an "old vs new" comparison in the Update statement to see if any valus in the database have changed. I found the main drawback was the need to create large amounts of hidden elements that are then passed into the DML procedure for evaluation. I came across ORA_ROWSCN in 10GR2 that reduces the amount of hidden form elements you need to submit. Its basically a new pseudo column in that database that provides the SCN (System Clock Number for the last time the row was updated) associated with individual rows when they were read. The basic steps to utilise this approach are as follows: 1) create table users (id number, name VARCHAR2 (100), address VARCHAR2 (100), tel NUMBER) ROWDEPENDENCIES / ROWDEPENDENCIES need to set as SCN by de...