In the previous post, I mentioned that for a programming environment fetching rows from the database, then the method of
might not be appropriate for those situations where the result set is known be a single row (eg primary key lookup).
A better option might be to call a procedure and get those outputs as parameters.
And I broke a cardinal rule… I effectively said “Here’s something that I know to be true…
In various programming environments, a common metaphor is to open a cursor on the database (a REF CURSOR in Oracle parlance), return that cursor handle to the calling environment, and then that cursor is used to fetch or “fill” a data object, which may map to a grid on screen, or just to an array in memory.
And that’s totally fine – its an effective means to obtain a result set from the database to the calling environment.
For example, a typical PLSQL routine might look like:
SQL Query has been taken 8 minutes to execute in First time. After that, it has been taken 5 seconds to execute in second time. I think, it has been taken output from buffer memory. So execution is fast.
To check actual time of execution time, i have cleared the buffer using below command and re-execute the query.
alter system checkpoint;
alter system flush shared_pool;
alter system flush buffer_cache;
If you've upgraded to APEX 5 and find yourself with an error complaining about the 'Source Used' attribute:
then you should thank APEX 5 for finding (and no longer tolerating) a logic bug in your application.
August 23, 2015 (Modified August 31, 2015) (Back to the Previous Article in this Series) I started using Linux in 1999, specifically Red Hat Linux 6.0, and I recall upgrading to Red Hat Linux 6.1 after downloading the files over a 56k modem – the good old days. I was a little more wise when […]