Top 10 signs your DBA might need to retire

The top 10 signs your DBA might need to retire:

1. Complains about these "new fangled stored procedures".
2. Rants about the good old days of Oracle PE (Punchcard Edition).
3. Thinks Thomas Kyte is a whipper-snapper (even with the beard).
   
4. Still demands all Oracle manuals in hardcopy.
5. Has a service request with Oracle Support to forward port the RBO to 11g.
6. Knows about Edgar's secret 13th rule.
7. Thinks Oracle Support went downhill when they moved the HQ to Redwood Shores in 1989.
8. Has larry@rsi.com in his address book.
9. Still replaces blank lines in PL/SQL with single line comments.
10. Has an open 10 year old Oracle Support "TAR" to fix a bug in version 7 which he/she wont close because of the "principal of the thing."
    

If you enjoyed this, you may also enjoy Top 10 signs your new Oracle DBA may not be all what he (or she) seems.

(Yep, still a slow week while I prepare for OOW and the AUSOUG conference, as well as teach a SQL course. I promise no more "DBA bashing" ;)

A little self promotion.....

This post is a little self promotion for SAGE Computing Services. If you're not interested in marketing, use the back button now! I promise I wont be doing this sort of post often.

To all the SAGE Computing Services fans out there (hi Mum!) we've had a chance to update our website. What made me particularly excited about the site is we've managed to include flashing text, JavaScript menus, Flash animations, and audio of the SAGE team singing "row, row, row your boat".

On a slightly more serious note, we've gathered the last 3 years of the 40 odd Oracle papers, presentations and masterclasses we've run in Australia and internationally, which you can now download. I must admit we've been a bit lazy in indexing this list, because marketing isn't really our thing.

To the various user group members out there, we're more than happy to support your group and present for you. Why? Well lets just say we're a bunch of Oracle geeks. So if you have a topic that you know we specialize in, particular Oracle development, Oracle RDBMS tuning, SQL, PL/SQL, Oracle Application Express (Apex), JDeveloper or Oracle Portal, drop us a line, and we'll work something out. As long as we get a free bottle of wine out of it, we're normally happy (no white wine please).

Hopefully the updated site will generate us slightly more revenue so we can take next Friday off, rather than sitting here posting about our updated site.

OOW Unconference - oh, me, me, me!

I've taken the chance to throw one of my presentations into the Oracle Open World Unconference ring and hopefully it'll be selected. You can check my session proposal on the Oracle Wiki:

Take a load off! Load testing your Oracle Apex or JDeveloper web applications

I note Andrejus Baranovskis has entered a JDeveloper paper too:

Oracle JDeveloper/ADF Real Life Story

....great to see a JDeveloper case study; more of these please Andrejus! I'm sure we're both very keen to meet our peers interested in JDeveloper too (assuming either of our sessions are selected of course ;) so please show your support if you can.

I think the Unconference is a great idea, giving lesser known mortals a chance to present something they're interested in at this mega-event. I must admit it's also an important learning opportunity on how to present in front of an American audience for myself; let's just say I need to learn to turn down some of my Australian colloquialisms ;)

I hope more attendees will take up this great opportunity, real users presenting real topics, it doesn't get much better than that.

Top 10 signs your new Oracle DBA may not be all what he seems

The top 10 signs your new Oracle DBA may not be all what he (or she) seems:

1. Arrives day 1 with "SQL For Dummies" in hand.
2. Searches for ORA-00600 errors on AskJeeves.
3. Is president of the local MS user group.
4. Resets the production database password to "manager" to make life easier.
5. Thinks utl_file is a package the developers wrote.
6. Is planning an organisation wide upgrade to Excel (but then shelves the plan as copy 'n paste from SQL*Plus to Excel proves too difficult).
7. Proclaims "A reboot a day keeps the Oracle demons at bay."
8. Uses ANSI SQL joins.
9. Looks blank at the mention of Thomas Kyte.
10. Proclaims that administration is impossible if SSMS isn't installed.

If you enjoyed this, you may also enjoy Top 10 signs your DBA might need to retire.

(This post courtesy of a slow blogging week while I prepare for OOW, and papers for the AUSOUG conference)

AUSOUG 2007 conference JDeveloper presentations

....logged under the "yes I'm an AUSOUG state committee member" department.

My first exclusive "you-heard-it-here-first" news post!

I'm happy to announce that Lynn Munsinger and Duncan Mills from Oracle will be presenting on JDeveloper at the Australian Oracle User Group (AUSOUG) conference in Melbourne and Perth respectively.

Last year Melbourne was very lucky to have Lynn present, and Lynn has decided to return again which is great news for everyone on the East Coast of Australia. For those who said to me they were impressed by what Lynn demoed last year, I'm pretty sure you haven't seen anything yet with the new JDev 11g release imminent, and these presentations straight from OOW.

For us West Coast Oracle developers, Perth is very privileged to have Duncan Mills, senior Principal Product Manager from Oracle, give us the low down on JDeveloper. Perth doesn't usually get to see such high caliber Oracle and Java speakers grace its fair shores. Do a little Google on Duncan Mills and you'll understand what I mean.

Given that I've seen zero JDeveloper presentations by local Aussie Oracle staff, this may be your only chance to see the latest for JDeveloper and ask the tough questions of very experienced Oracle staff. So make sure to sign up for this year's November conference in Perth or Melbourne, and I look forward to seeing you there.

The zen of the Oracle development landscape

Grant Ronald has recently blogged about Modernising your Forms Applications - SOA or bust, which (once again?) revisits the perception (or myth?) that Java is the one and only future of Oracle's development. I'd like to revisit why I think this perception has come about.

I think one of the reasons (and I emphasis the word one here, there are certainly more) Oracle developers look to Java and therefore JDeveloper by default as the Oracle development future is a matter of circumstances that eventuated in the past.

Around 1998 through 2004 Java was the buzz in the development industry and it was pretty important change time for the industry. Languages were revolutionized, the web was coming to the fore, and Java is famous for being the first cab off the ranks so to speak in the Web programming world (thanks to its servlet technology - which it is now partly infamous for).

I believe many Forms programmers came to the conclusion that Forms wasn't the future because of its clunky 2 tier architecture (later hammered into 3 tier) and plain-Jane interfaces. As such they were interested in what else was happening out there way back when. It just happened that Oracle invested in JDeveloper at the time and through Oracle's marketing, coupled with the buzz around Java, it gained popularity and became the perceived future of Oracle development. Forms programmers picked up on this fact and stored it away in their little box of tricks.

Then the world moved on.

Today those same typical Forms programmers are facing the following problems:

1) The majority of Forms systems are now legacy and it has taken them a long time to come around to adopting new technologies for various reasons regardless of their originally interest in other technologies, due to organisational lack of mobility in technology adoption, lack of in-house skills, lack of interest by management to move on and so on - take your pick. So their initial interest in other technologies has been stalled by the slow moving IT corporate world. It's hard to move to a new technology when you have to fix current problems in existing legacy systems.

2) There has been an incredible amount of change in the industry between 2000 and 2007 (as usual in the IT industry). Traditional Forms and PL/SQL Oracle programmers are outside the whole web world, revolution in web scripting languages, scratch their head at the term Ajax (it's something Google does isn't it?), have very little exposure to industry wide frameworks (as separate to inhouse frameworks), and so on. Keeping up with all this change is a full time job, much easier to keep the blinkers on, do what your job demands you to do, and just keep with what you learned way back when.

3) The perception that development of Forms from Oracle has stalled.

4) A potential alternative Oracle Application Express (Apex - formally HTML DB) has only appeared to have become (again a perception thing, not necessarily reality) a viable mature development alternative more relatively recently.

....that because of these issues and perceptions (and I can't emphasis the word perception for this discussion enough - don't start arguing that's what I believe please), because typical Forms programmers haven't kept up with all the changes, because Forms is an old technology, because the marketing has at times focused on Fusion and JDeveloper and not Apex....

....that because of all these perceptions.... and how history eventuated.... and given a reluctance to give up on the potentially false or outdated perception learned way back when, that Java is still the only way to go....

.... that we see Forms programmers coming back again and again to thinking JDeveloper/Java is the future of Oracle development, and then becoming terribly disillusioned when they struggle with Java, JDev and ADF, can't see why the huge frameworks don't fit into their simple problem sets, struggle with the huge learning curve of adopting not one but several new technologies, and see an easier alternative in Apex, or scripting languages, or .Net or take whatever your pick in what you're more familiar with (it's always easier to say technology X is better than Y when you know X, but you don't know Y - that's human psychology for you).

Now given this whole discussion, does this mean I think Java and JDeveloper don't have a viable future for Oracle development? Not at all. For myself I've overcome the JDeveloper learning curve moving from Forms and I'm very excited about the future of the product. The rich AJAX components in JDev 11g ADF Faces Rich Client has me jumping up and down in excitement .... I can't believe I don't have to do hardly any JavaScript programming (don't get me started Apex programmers) at all to get these great AJAX enabled components in my web application .... Web 2.0 here we come.

For you and your organisation, like Grant says in his blog, to paraphrase, there are a number of ways to skin a cat, and what technology you pick should be dependent on your circumstances, or more precisely your organisation's circumstances. Don't invest in one of these technologies before understanding your organisation's circumstances or you will get burnt. For example investing in a huge Java project with just PL/SQL programmers without any Java training or experience will certainly burn you unless you're very lucky. And you should have known that fact before you start. That's the risk of falsely thinking Java is the holly grail of development. The same holds true for investing in an Apex project, a scripting language project and so on, there is no holly grail in development, particularly if you have none of the needed skills or the tool is badly suited to your environment. And for the record (you can quote me) there will never be a holly grail (unless you consider turning all the computers in the world off) – so get over it (the exception being of course Lisp ;).

So take Grant's point on board. Java and JDeveloper match certain problem sets and backgrounds. As does Apex as does Forms..... let your mind free itself from what you learned before and re-assess the Oracle development landscape today, to what suits your needs.

....and thus the title of this post.

Now, I seem to have broken my soapbox. Until I find another one, I'll keep the blog free of rants for a while. I think it's a time for a humorous post. Maybe I'll pick on DBAs or something fun.

Usual disclaimers to stop the unnecessary flames:

1) Please note I'm not trying to put all Forms programmers in one outdated boat. There is always a bell curve of people and skills; people who are as much as in the box as out, so put yourself in whatever box makes you happy for this discussion. When I say "typical" Forms programmers I'm drawing from my experience as a consultant and I'm referring to a generalisation of the Forms programmers I'm meeting on a day by day basis, not a specific person or group. There are certainly Forms programmers who I meet who know everything outside the Forms sphere too.

2) It's a false perception that Forms development from Oracle has stalled, as thanks to Grant's blog we can see there is still changes occurring in the Forms arena, just more subtle than before.

3) For the readers of one of my original posts A career path for Oracle developers - consider JDeveloper!, you will certainly be able to see a certain maturing in my thoughts about this, thanks to many discussions with Apex specialists, JDeveloper experts and other contemporaries.

OOW Blogger catchup

OOW 2007 is nearly upon us, and Mark Rittman has kindly organised a meetup at the Thirsty Bear on Tuesday 13th 7pm for all the Oracle bloggers.

Of course the challenge is on not to talk about Oracle all night. Maybe a game of "If you mention Larry it's a round of drinks" is in order ;)

3 things you can do at home *AND* work to reduce your IT environmental footprint

In honour of Blog Action Day, this post is given over entirely to the discussion of ways in which we as IT professionals, developers, administrators, team leaders and managers can help to reduce our footprint on the planet, reduce our carbon emissions, and enable our employees, employers, and associates to reduce theirs.

3 things you can do now at home AND work to reduce your IT CO2 footprint:

Power down your home *AND* work computers each night, and turn them off a the wall socket.

Most would know that there is a number of ways to "switch off" your machine, including stand by, hibernate and shut down. But the power consumption of your machine doesn't stop there. It's important to note that anything that has a transformer (the old 'power brick') such as a laptop, LCD screen, printer / fax / MFP, continue to consume power when plugged in to a live power outlet (i.e. the switch at the wall is on), regardless of whether the appliance is powered off or not.

Even mobile phone (cell phone) chargers plugged in and turned on draw a current, whether or not the phone is actually attached. Treehugger makes the claim that 40% of the energy used for electronics in your home is used while these devices are turned off.

And here's the trick, many consumers are becoming conscious of doing this at home to save some dollars on their electricity bill, but how many of us think of turning off our PCs and powered devices at work when we leave for the day? I haven't been at an IT department or an organisation yet that advocates this at a department or organisational level.

Concerned about the "Wear and Tear" of powering your devices on and off? Well, there is anecdotal evidence that powering a machine down every day may increase wear and tear on components such as the hard drive, however Google Research reported "Surprisingly, we found that temperature and activity levels were much less correlated with drive failures than previously reported."

Turn off your "flashy" screen savers

Screen savers use as much power as a screen in normal use. Change your power options to turn the screen off after a period of inactivity, and don't use the screen saver. The original need for them has now all but disappeared with modern screens, the burn in effect doesn't occur in modern monitors, but "burn-ing" of fossil fuels to show that boring Windows logo is very much a problem.

Mystery Machines

Mark Monroe, Sun Microsystem's Director of Sustainable Computing, coined the term Data Centre Drift to describe the situation where a server is installed to run an application, eventually that application is no longer needed and is turned off, but the server remains on, serving no purpose but to use power and take up space. He also described the role of server virtualisation in minimising the number of physical machines required and save energy and emissions in the data centre. Maybe it's time for an audit of your servers to save a few CO2 tonnes and decommission that redundant server?

Many thanks

Many thanks to my friend Ben Harrison for helping me to put this post together. We hope that this post will make at least a few out there think about changing their IT practices at home AND work for the better of us all.

4 things I read more recently (about all things "developer" and "programmer")

4 things I read more recently about "developer stuff":

• Cost of Developer Interruptions - having been a consultant at many customers' sites, I'm used to being stuck in all sorts of odd locations, including cupboards, hallways and kitchens. Mostly the environments are noisy, and interruptions are undoubtedly a productivity killer, especially to my Internet surfing. David Carr blog's about his observations on this issue.

• Programming can ruin your life - boy, I nearly feel like Marvin the Robot after reading this article posted on devizen. I'm not depressing you am I?

• Thirteen Patterns of Programmer Interviews - it would be funny if it wasn't so true -- I haven't had to undertake a serious interview for just on 7 years, having realised they're all a farce. Greg Jorgensen blogs at Typical Programmer the kind of joke interviews we all need to go through at some stage. Thanks to devizen for the original link.

• Younger developers are better & faster? - apparently old people "learn dumber" at programming. Rey Bango asks should old programmers retire into management and let all the whipper-snappers take over the programming world? At 32 years my opinion is, um, ah, am I considered young or old? Dunno.
  

New OTN article: Integrating JDeveloper and Designer's Table API

I'll tag this post under "another 23 + 6.2 seconds of fame".

Thanks to OTN, my article Integrating the Oracle Designer Legacy Table API with Oracle JDeveloper 11g ADF Business Components has been published, and even indexed on their front page.... be quick! I'm sure it'll be gone soon.

Without attempting to sound like a complete amateur, but indeed sounding like a complete amateur, it's pretty neat to be published at this international level. Up till now most of my articles and white papers have been published in the Australian Oracle User Group's (AUSOUG) magazine Foresight. Suddenly I've an article up in lights on the OTN front page, and for the record, a big cheesy grin to match.

My Mum will be so proud..... except she doesn't understand anything I do and listens with a blank look most of the time. I think I lost her way back in 1998 when I mentioned the acronym RDBMS.

Thanks to Justin Kestelyn and the Oracle team for accepting and editing the article, and putting up with my poor grammar, spelling mistakes, and outrages demands.

This of course makes me excited that hopefully Oracle will accept my next article, a romance-crime-mystery Oracle-Forms crossover.

Apex Cascading LOVs revisited

Like the JDev community, the Apex community has plenty of blogs and example sites on achieving certain functionality which cuts down the learning curve or reinventing the wheel. I recently had the immediate requirement for a cascading LOV in Apex 2.0, and went with Carl Backstrom's example on his sample site.

For my own notes, and possibly of benefit to others, I'd like to extend Carl's example by describing the actual steps needed to implement the solution.

A cascading LOV is where a web page containing 2 poplists called Select Items in Apex, or sometimes loosely referred to as List-Of-Values (LOVs), where the 2nd poplist's values are dependent on the 1st poplist's current selection. When the user selects a value in the primary LOV, the secondary LOV should show a subset of values relevant to the primary value rather than all values.

To implement Carl's example follow these steps:

1) At the application level create an Application Item named: TEMPORARY_ITEM. Application Items are created through the Shared Components page for your application. On creating the Application Item accept the other defaults.

2) Also within the Shared Components, create an Application Process. Carl's example assumes the name of the process is "otn_Select_XML", but you can call it anything you want such as RESOURCE_LIST. On creating the Application Process, ensure the Process Point is "On-Demand", and enter the Process Text as supplied on Carl's website -- essentially an anonymous PL/SQL block with a cursor that constructs a list of items.

3) Within the Application Process change the cursor's SQL query to what ever you want your secondary poplist to show, for example as follows:

select description, code from resources where type_code = :TEMPORARY_ITEM

Note how the query needs to have a predicate (where clause) that is restricted by TEMPORARY_ITEM.

Ensure that within the cursor for loop, you change the column names for the rec pl/sql datatype to match that of your select list aliases in the cursor.

4) Again within the Shared Components, create a List of Values entry that is either a static list of values, or a query driven dynamic list, which you will use for your primary LOV. For example:

List of values name: RES_TYPE_LOV
List of values query: select name d, code r from resource_types order by 1

5) In the web page that will contain the cascading LOVs, within the page's attributes (accessible in Apex 2.0 by clicking on the Edit Attributes button near the top of the screen), in the HTML Header option, embed the JavaScript code from Carl's webpage.

Note that Carl's JavaScript example makes a number of calls to method $x which isn't supported in Apex 2.0. Thanks to the comment in this blog entry by Patrick Wolf, you may replace the call to $x with html_GetElement. If you're using a later Apex version you should be fine.

An alternative easy hack to get this working is to include the function $x in the JavaScript code you just included before the other routines:

<script language="JavaScript1.1" type="text/javascript">

/* begin $x functions */
function $x(pNd){
  try{
    var node;
    switch(typeof (pNd)){
      case 'string':node = document.getElementById(pNd);break;
      case 'object':node = pNd;break;
    default:node = false;break;
    }

  if(node.nodeType == 1){return node;}else{return false;}
  }catch(e){return false;}
}

....other functions....
</script>


The $x function here comes from htmldb_html_elements.js, presumably a JavaScript library available in later versions of Apex?

6) Note within the JavaScript code you just copied in, within the function get_AJAX_SELECT_XML, there is a call to a function htmldb_Get on approximately the 3rd line of the function. Within that function call, there is the following parameter:

'APPLICATION_PROCESS=otn_Select_XML'

otn_Select_XML refers to the Shared Component Application Process you created some steps back. Change otn_Select_XML to whatever you called the Application Process.

7) Still within the web page that you're interested in showing the cascading LOV, create your primary LOV field, a Select Item, named RESOURCE_CODE for example. Base it on the LOV you created in the previous step (ie. RES_TYPE_LOV). Accept the other defaults.

8) Now create your secondary LOV field as a Select Item, named RESOURCE_TYPE for example. Alternatively the actual item you want to be the Select Item may already be on the page as a Text Item for example, so just change it from a Text Item to a Select Item. Base the Static Item on a static list with one dummy item.

9) Once the poplist is created, invoke the editor for the primary poplist, and within the HTML Form Element Attributes option, specify a JavaScript onChange event as specified at Carl's site:

onchange="get_AJAX_SELECT_XML(this,'P37_SELECT_DROP_XML')"

You'll note the onchange code mentions P37_SELECT_DROP_XML. This in fact should be whatever you specified for your secondary Select Item's name.

....

That's all the steps you should need to do. If I've missed out any obvious steps let me know and I'll update the example for the benefit of others.

Thanks to Carl Backstrom for the original example. Note that Patrick Wolf has a more generic solution suitable to later Apex versions than 2.0 that could be better solution for your site.