Should I take that Oracle Forms 6.0 PL/SQL job, Steven?

I received this note from a reader from Brazil:

I am a PL/SQL developer for 6 years now. I recently received a job offer to develop in Oracle Forms 6.0, Reports and HTMLDB. I think these are older technologies. I don't know if it is a step back to work on these products, but I do know that I want to develop in Oracle Database 12c, Application Express, and other new technologies. One thing I have found is that it is more and more difficult to find a job in Brazil that only requires PL/SQL experience.

And this is what I said:

No doubt about it, Oracle Forms 6.0 and HTMLDB are not the leading edge of PL/SQL-based Oracle technologies!

You would be much better off working at a company that has upgraded to Oracle Database 12c, has a strong commitment to fully leveraging SQL and PL/SQL, uses Application Express for website and intranet development, etc.

But keep the following in mind:

There are not a whole lot of companies who have upgraded to 12.1.
Don't be like me. I "got away" with specializing very narrowly in PL/SQL. Normal humans don't have that luxury. I suggest that at a minimum you need a working knowledge of Java, Javascript, and regular expressions.
I probably don't have to tell you this, but you have to live in the world as it is, not how you want it to be.

So maybe you should take that old technology job. If you cannot afford to keep looking, that job might end up being a great platform for you to explore the newer technologies as part of planning their upgrade strategy.

In other words: take the interview and then find out what their future plans. You could end up being in the right place at the right time to take the lead in working with 12.1, APEX and more. You could become the in-house superstar and have a long, successful career right there.

And regardless of whether you take the job or hold off, continuing your search, there is absolutely no reason to put off learning about and using the latest technologies.

Download Oracle Database 12c here.

And then, most important of all, pick a project you'd like to work on. In other words, make it as real as possible.

Build an app to keep track of lost kittens in your neighborhood, or a simple to-do list manager or....you name it. Pick an app you really like and then replicate it. You don't have to come up with a wildly, new original idea to hone your skills.

You just need focus and motivation.

Hope this helps!

Running out of PGA memory with MULTISET ops? Watch out for DISTINCT!

A PL/SQL team inside Oracle made excellent use of nested tables and MULTISET operators in SQL, blending data in tables with procedurally-generated datasets (nested tables). All was going well when they hit the dreaded: ORA-04030: out of process memory when trying to allocate 2032 bytes They asked for my help. The error occurred on this SELECT: SELECT * FROM header_tab trx WHERE (generated_ntab1 SUBMULTISET OF trx.column_ntab) AND ((trx.column_ntab MULTISET EXCEPT DISTINCT generated_ntab2) IS EMPTY) The problem is clearly related to the use of those nested tables. Now, there was clearly sufficient PGA for the nested tables themselves. So the problem was in executing the MULTISET-related functionality. We talked for a bit about dropping the use of nested tables and instead doing everything in SQL, to avoid the PGA error. That would, however require lots of wo...

How to Pick the Limit for BULK COLLECT

This question rolled into my In Box today: In the case of using the LIMIT clause of BULK COLLECT, how do we decide what value to use for the limit? First I give the quick answer, then I provide support for that answer Quick Answer Start with 100. That's the default (and only) setting for cursor FOR loop optimizations. It offers a sweet spot of improved performance over row-by-row and not-too-much PGA memory consumption. Test to see if that's fast enough (likely will be for many cases). If not, try higher values until you reach the performance level you need - and you are not consuming too much PGA memory. Don't hard-code the limit value: make it a parameter to your subprogram or a constant in a package specification. Don't put anything in the collection you don't need. [from Giulio Dottorini] Remember: each session that runs this code will use that amount of memory. Background When you use BULK COLLECT, you retrieve more than row with each fetch, ...

PL/SQL 101: Three ways to get error message/stack in PL/SQL

The PL/SQL Challenge quiz for 10 September - 16 September 2016 explored the different ways you can obtain the error message / stack in PL/SQL. Note: an error stack is a sequence of multiple error messages that can occur when an exception is propagated and re-raised through several layers of nested blocks. The three ways are: SQLERRM - The original, traditional and (oddly enough) not currently recommended function to get the current error message. Not recommended because the next two options avoid a problem which you are unlikely to run into: the error stack will be truncated at 512 bytes, and you might lose some error information. DBMS_UTILITY.FORMAT_ERROR_STACK - Returns the error message / stack, and will not truncate your string like SQLERRM will. UTL_CALL_STACK API - Added in Oracle Database 12c, the UTL_CALL_STACK package offers a comprehensive API into the execution call stack, the error stack and the error backtrace. Note: check out this LiveSQL script if...

ColemanFebruary 5, 2015 at 8:00 PM
Brilliant and sound advice, Steven.
iudithFebruary 6, 2015 at 12:27 PM
Hello,
Oh, I really liked it, Steven !

Learning Oracle12c and APEX and ... + "keeping track of lots of kittens"
is an excellent definition for enjoying life ...
especially after your retirement, when you have the freedom of choice ...

Unfortunately, many companies today do tend to easily throw away entire projects,
after tens of years of work invested in them ... just for replacing them with
other inferior projects, whose only point is that they use a newer technology ...

But, technology is only one thing, and project functionality is another and this
is what in fact matters to the users ...

On the other side, each technology is "intricate enough" for stimulating the tendency to become a "guru" in that specific technology, for being really able to apply it at a very high level and come up with ingenious solutions for each and every situation out of that technology ...
If we already talk about the old good Oracle Forms ... I am still extremely proud
up to this day from having created business charts in my applications already starting from SQL*Forms version 3.0 !!! -- and, of course, specializing them
across the higher versions ...

If somebody wants to survive, I would rather advise him to prefer the database itself
upon ANY of the other technologies ...
As Tom Kyte always says, front-end technologies come and go, and it might only depend on a momentary caprice of one manager or another to decide to replace a technology ... and then through you away no matter how valuable you are ...
The database, instead, will always be THE strategic component of any work place ...
so, the best advise that I would give a young person today would be to focus
on the database, and less on the other things around.

Best Regards,
Iudith Mentzel

Steven FeuersteinFebruary 16, 2015 at 4:18 AM
That is very good advice, Iudith. Thanks for offering it up.

Obsessed with Oracle PL/SQL

Search This Blog