Thursday, October 22, 2015

Most important PL/SQL coding standards?

Received this request today via email:
I was at the MOUG Fall Conference in Chicago a few weeks ago and enjoyed your presentation on the result cache. It’s already paying dividends for us. Thanks for coming and sharing. I have a question for you, and maybe you’ve already written about this and can point me toward an article or blog post. We will be revising our coding standards, which are rather loose and largely ignored, and I want to try to promote those that will give us the most benefit. What is your top ten list of the most important coding standards to implement? Thanks for your time, and I hope to see you at OOW. It will be my first trip there.
And I replied:
I love these kinds of requests, because it gives me an opportunity to take a fresh look and publish something on my blog. :-) I don’t think I will be able to get back to you until after OOW, hope that works OK. Please do come up and say hi if you see me!
And then I thought: wait a minute, let's ask all my fellow Oracle Database developers "out there", see what all of you think. 

So here I am, there you are - and I'd love to hear from you:

What do you think are the most important coding standards for PL/SQL developers to follow?

By the way, check out some existing, published standards and frameworks here

Nov 6 update: it's been a busy post-OOW week, so I haven't been able to formulate my complete answer yet. I like lots of the ideas submitted in the comments. But I have come up with nine keywords to drive my "most important." They are:

1. MAXSQL - maximize use of SQL first and foremost
2. SPOD  - single point of definition
3. TRACE - production-available application-level tracing
4. LOG - consistent, encapsulated error logging
5. BULK - avoid row by row
6. OBVIOUS - make your code tell its own story, comment when it can't
7. NESTPROG - use nested subprograms
8. DECLARE - use declarative features of language
9. WARN - use compile-time warnings

November 12 2015: I have published an 8 minute video explaining these Top Nine. Hope you like it!

Tuesday, October 6, 2015

Execute any SQL statement from within a Application Express app? Sure, why not? Um.....

Received this question today:
We are planning to develop  a product with APEX and is it possible to  execute free sql inside an apex application? I mean is it possible to have a SQL execution window inside the APEX application like we execute inside an Oracle SQL developer?

Sure, why not? 

Well, actually, there are all sorts of reasons "why not", right?

But, yes, it is certainly technically possible to do this - and not very difficult. 
  • Create a page in Application Express.
  • Add a Text Area item and give your users lots of room to write lots of SQL. 
  • Add an Execute button.
  • Create a process that fires on that button, and contains code like this:
         EXECUTE IMMEDIATE :P1000_your_sql;

Then your users will then be able to do all sorts of things:
  • Create a new table (!)
  • Truncate an existing table (!!)
  • Set values of columns to NULL (!!!)
  • etc.
They will not be able to:
  • Execute a SELECT and see the results. For that you need an INTO clause.
  • Execute a DML statement that requires bind variables. For that you need a USING clause (or concatenation).
But they will be able to screw up your application really well!

So, seriously, you do NOT want to do that! 

Suppose, however, that you wanted to let a power user execute an ad-hoc single value query and see the result? In that case, something like this might almost be reasonable:

   value_out VARCHAR2(32767);
   EXECUTE IMMEDIATE :P1000_your_sql INTO value_out;


   :P1000_your_sql := value_out;

The INTO clause means that you must execute a single-value, single-row select.

The ROLLBACK ensures that any changes you try to sneak in will be rolled back....well, unless your power user has truly super powers and was able to previously create an autonomous transaction function and then call it in the query.

But if you've got a user who can do that, you've got bigger problems than anything I can address in this somewhat tongue-in-cheek post!