Enable/Disable Bind Variable in SQL*Plus
As state in the title, this post is about turning off the bind variable in SQL*Plus. Actually, this is also applicable in PL/SQL Developer and Toad but I'll be discussing more on SQL*Plus. You see, I have a problem wherein whenever I load my backup data (saved as insert statements) and there are ampersand (&) or colon(:) somewhere in the script, SQL*Plus will ask me for an input. Of course, I don't need that because as a backup, I want to load the data as it is. And when migrating 60MB or more, then it isn't funny to update the query one by one. The good thing is, I don't actually need to update the query because there's an answer to my problem. And it's pretty damn simple.
Syntax
set define off
Oh yes, that's just one line that will solve my misery. Well, it's all about my ignorance. To turn back on, then do the opposite as below.
Syntax
set define on
Oracle WITH Clause (Subquery Factoring)
WITH clause was introduced in Oracle 9i to provide powerful new syntax for enhancing query performance. It optimizes query speed by eliminating redundant processing in complex queries.
WITH Clause Syntax
WITH alias_name -- alias for the aggregate_query AS (aggregate_query_here) SELECT... -- Beginning of the query main body
It should be noted that multiple aggregate queries can be defined in the WITH clause as below.
WITH alias_name1 AS (agg_query1) , alias_name2 AS (agg_query2) SELECT...
When using subquery factoring, think of the aggregate_query as an in-line view. Actually, it is a view but a temporary one. Instead of creating a permanent view accessible in the database, you are creating a temporary one exclusively used by your main query.
Usage
I primarily use this in creating adhoc queries, reports and extractions. Of course, you can just create a view to accomplish this task. However, there are times wherein you are not allowed to create additional objects in the database for one reason or another. In that case, this subquery optimization comes very handy.
Caveat
You can't use this inside Oracle Forms. It also doesn't work inside stored procedures or anything with PL/SQL in it. At least I'm talking about until 11g.
Oracle CASE WHEN Statement
Another oracle sql statement that you may need in order to simplify and optimize your code is the use of CASE statement. Here's how it is being used.
Syntax #1
CASE [ expression ]
WHEN condition_1 THEN result_1
WHEN condition_2 THEN result_2
...
WHEN condition_n THEN result_n
ELSE result
END
Example
SELECT last_name, commission_pct,
(CASE commission_pct
WHEN 0.1 THEN ‘Low’
WHEN 0.15 THEN ‘Average’
WHEN 0.2 THEN ‘High’
ELSE ‘N/A’
END ) Commission
FROM employees ORDER BY last_name;
Syntax #2
CASE
WHEN [ condition_1 ] THEN result_1
WHEN [ condition_2 ] THEN result_2
...
WHEN [ condition_n ] THEN result_n
ELSE result
END
Example
SELECT m.paper_type ,
m.paper_brand ,
m.paper_grammage,
m.paper_width ,
m.paper_length ,
m.paper_stock_no,
(
CASE
WHEN NVL(smc.qty_reserved_onhand,0) != NVL(st.sum_qty_r_oh,0) THEN 'QROH NOT TALLY'
WHEN NVL(smc.qty_reserved_incom,0) != NVL(st.sum_qty_r_incom,0) THEN 'QRINC NOT TALLY'
WHEN NVL(smc.ton_reserved_onhand,0) != NVL(st.sum_ton_r_oh,0) THEN 'TROH NOT TALLY'
WHEN NVL(smc.ton_reserved_incom,0) != NVL(st.sum_ton_r_incom,0) THEN 'TRINC NOT TALLY'
END
) ERROR_MESSAGE
from paper_stock_master m
Personally, I use Syntax #2 most of the time. I don't know why but maybe it just happened that I find it more suitable to use in the situations that I needed the CASE statement.
Difference Between DECODE and CASE WHEN
The most fundamental difference between the two oracle statements is that in DECODE, you are comparing a field or value in a given set of values or fields. It's actually a shorthand for IF..ELSIF..ELSE statement with the condition all set to equals (=). CASE WHEN is almost the same but you can use any conditional operator (i.e, =,!=, >, >= , <, <=, etc) thereby giving you more freedom and flexibility in writing your code.
In may instances CASE WHEN helped me reduce the number of lines of my codes as well as optimize the performance. On top of that, I no longer need a full pl/sql program with multiple queries and even cursors to be able to provide the result that a simple CASE statement can provide. However CASE, like any other sql commands, is only applicable for certain scenarios. It's not a magic keyword that will solve/apply to everything. So you have to weigh your options if you need it or not.
Ciao!
Could not locate OCI dll Error
If you are using 10g client with PL/SQL developer, you may encounter the message "Initialization error: Could not locate OCI dll" when launching PL/SQL Developer. It does not happen with the 8i client so I already suspected that it must be with the 10g client that I recently installed. Luckily, I found this thread in Oracle OTN forum and the solution seems to be easy.
All I have to do is copy a whole bunch of files from the ORAHOME folder to ORAHOME\bin. It seems like PL/SQL Developer is hardwired to find the files under the bin folder. It did the trick and my sql editor is now working. I hope it fixes yours too.
Here's the screenshot of the files I copied. Take note that I copied them instead of just moving so as not to break anything.
How to Get Oracle DB Version
I only know two ways of getting the Oracle DB version you are currently connected to. They are as follows:
SELECT *
FROM product_component_version
SELECT *
FROM v$version
This is quite handy if your program has SQL commands that are not applicable for earlier versions of Oracle Database.
