Using Date in Where Clause - oracle

I am trying to place a date in a where clause. I want to update all rows in which the date column is before or after a certain date. How do I specify that I only want to update these columns. Here is the coding that I have so far (not including specific column names):
update table1
set column1 = value
where (select date from table2) < date;
Am I on the right track?
Also, could someone please explain the difference between SQL and PL/SQL. I am taking a class in PL/SQL at the moment. Whenever I post a question on this forum I say that I have a question in PL/SQL, but the people who answer my question say that a certain function - update/if/case/etc. - is a SQL statement and not a PL/SQL statement. What is the difference?
-Neil

Your update statement
update table1
set column1 = value
where (select date from table2) < date;
is correct and it will work but only if the inner query (select date from table2) returns a single row. If you are trying to compare to specific date you don't need the inner query, for example:
update table1
set column1 = value
where to_date('01/02/2012', 'DD/MM/YY') < date;
You can adjust date format mask to whatever format of data you prefer. to_date will convert from char to date type, and to_char will do the opposite.
SQL is a standardized query language that is supported by all compliant relational databases (with some proprietary extensions sometimes). SQL is not a programming language. PL/SQL is a procedural programming language that is supported on Oracle only (Postgres has similar syntax). PL/SQL is SQL + regular programming language features like conditional statements (if/else), loops (for), functions and procedures and such. PL/SQL is used whenever it's too difficult or impossible to get some data using SQL solely.

As Aleksey mentioned, your query is correct but you need to either [1] set conditions around the sub-SQL to only return ONE record or [2] make sure the data in tabl2 only has ONE record when it runs.
ie
If you have to refer to data from another table in your WHERE clause consider explicit joins (example in SQL Server) ...
update t1
set t1.column1 = value -- <-- some arbitary value here I assume?
from table1 t1
inner join table2 t2
on (t2.key = t1.key) -- you need to specify the primary keys of the tables here
where t2.date < t1.date
That way you are not assuming table2 has only one record. It can have many records as long as they relate to table1 via their keys/indexes and the WHERE clause simply makes sure you only UPDATE based on data from table2 that has a date LESS THAN the date in table1.

Related

why SYS_GUID() gives two different records when used in inner query? [duplicate]

Here is the example SQL in question; The SQL should run on any Oracle DBMS (I'm running 11.2.0.2.0).
Note how the UUID values are different (one has 898 the other has 899) in the resultset despite being built from within the inline view/with clause. Further below you can see how DBMS_RANDOM.RANDOM() does not have this side effect.
SQL:
WITH data AS (SELECT SYS_GUID () uuid FROM DUAL)
SELECT uuid, uuid
FROM data
Output:
UUID UUID_1
F8FCA4B4D8982B55E0440000BEA88F11 F8FCA4B4D8992B55E0440000BEA88F11
In Contrast DBMS_RANDOM the results are the same
SQL:
WITH data AS (SELECT DBMS_RANDOM.RANDOM() rand FROM DUAL)
SELECT rand, rand
FROM data
Output:
RAND RAND_1
92518726 92518726
Even more interesting is I can change the behavior / stabilize sys_guid by including calls to DBMS_RANDOM.RANDOM:
WITH data AS (
SELECT SYS_GUID () uuid,
DBMS_RANDOM.random () rand
FROM DUAL)
SELECT uuid a,
uuid b,
rand c,
rand d
FROM data
SQL Fiddle That Stabilizes SYS_GUID:
http://sqlfiddle.com/#!4/d41d8/29409
SQL Fiddle That shows the odd SYS_GUID behavior:
http://sqlfiddle.com/#!4/d41d8/29411
The documentation gives a reason as to why you may see a discrepancy (emphasis mine):
Caution:
Because SQL is a declarative language, rather than an imperative (or procedural) one, you cannot know how many times a function invoked by a SQL statement will run—even if the function is written in PL/SQL, an imperative language.
If your application requires that a function be executed a certain number of times, do not invoke that function from a SQL statement. Use a cursor instead.
For example, if your application requires that a function be called for each selected row, then open a cursor, select rows from the cursor, and call the function for each row. This technique guarantees that the number of calls to the function is the number of rows fetched from the cursor.
Basically, Oracle doesn't specify how many times a function will be called inside a sql statement: it may be dependent upon the release, the environment, the access path among other factors.
However, there are ways to limit query rewrite as explained in the chapter Unnesting of Nested Subqueries:
Subquery unnesting unnests and merges the body of the subquery into the body of the statement that contains it, allowing the optimizer to consider them together when evaluating access paths and joins. The optimizer can unnest most subqueries, with some exceptions. Those exceptions include hierarchical subqueries and subqueries that contain a ROWNUM pseudocolumn, one of the set operators, a nested aggregate function, or a correlated reference to a query block that is not the immediate outer query block of the subquery.
As explained above, you can use ROWNUM pseudo-column to prevent Oracle from unnesting a subquery:
SQL> WITH data AS (SELECT SYS_GUID() uuid FROM DUAL WHERE ROWNUM >= 1)
2 SELECT uuid, uuid FROM data;
UUID UUID
-------------------------------- --------------------------------
1ADF387E847F472494A869B033C2661A 1ADF387E847F472494A869B033C2661A
The NO_MERGE hint "fixes" it. Prevents Oracle from re-writing the inline view.
WITH data AS (SELECT /*+ NO_MERGE */
SYS_GUID () uuid FROM DUAL)
SELECT uuid, uuid
FROM data
From the docs:
The NO_MERGE hint instructs the optimizer not to combine the outer
query and any inline view queries into a single query.This hint lets
you have more influence over the way in which the view is accessed.
SQL Fiddle with the NO_MERGE hint applied:
I'm still struggling to understand/articulate how the query is being re-written in such a way that sys_guid() would be called twice. Perhaps it is a bug; but I tend to assume it is a bug in my own thoughts/code.
Very interesting.
We can use the materialize hint to fix it to.
WITH data AS (SELECT /*+materialize*/SYS_GUID () uuid FROM DUAL)
SELECT uuid, uuid
FROM data;
1 F9440E2613761EC8E0431206460A934C F9440E2613761EC8E0431206460A934C
From my point of view, if we can change the result of a query just by adding a hint, there is an Oracle bug.
Maybe we have to ask metalink to check it...

Creating Easy Way to update variables in large code

I am using Oracle SQL Developer and have a rather large query built. The query is going to be run on a monthly or quarterly basis. I was wondering if there was a way that I can do a declare statment up top and then in the code just reference these variables created. That way when someone wants to run the query they can just change the dates at the top of the code rather then have to dig through all of it. I am kind of new to Oracle SQL Developer but I know in other sql codes I built I could simply declare the variable and then set it and then in the code call the variable name. Below is an example of what I know how to do but i am having trouble in Oracle SQL Developer.
Example: I have a data base that contains the columns Business, business type(small,medium,large) number of deposits, deposit amount and deposit date. I want to build a query that outputs a quarterly summary of the number of deposits and the deposit amount and be able to change the quarter and size of the business.
Example Code from my previous SQL expereince this is an example of what I am trying to do since i can not disclose my code with the table names etc in them.
Declare #busstype,#qbegindate,#qenddate
Set #busstype = 'small'
Set #qbegindate = '01-JAN-2013'
Set #qenddate = '01-MAR-2013'
Select business,numberofdeposits,depositamount
From business_transactions
Where ('#qbegindate'<=depositdate<='#qenddate'
And businesstype = '#busstype')
Group By Business
The results would list out the businesses name and then the total deposits and total amount.
I know this code is not right but its just an example of what I am looking to do in Oracle SQL Developer. The query I have built is working fine I just find it a pain to dig through the code to change dates and criteria and was wondering how I would do something like this since i have figured out that I am not able to do this in ORACLE Sql Developer.
Here is an example with predefined variable:
set feedback off
var abc varchar2
begin
:abc := 'abc';
end;
/
select :abc as a from dual;
Output:
A
--------------------------------
abc
Common table expressions allow variables to be defined at the top of the query. For performance and style reasons this is generally not a good way to
use common table expressions. The advantage is this query can be run in any IDE and it is completely self-contained.
--Variables - change these before running.
with busstype as (select 'small' value from dual),
qbegindate as (select date '2013-01-01' value from dual),
qenddate as (select date '2013-03-01' value from dual)
--Query - do not modify code below.
select business,numberofdeposits,depositamount
from business_transactions
where depostiddate between
(select value from qbegindate)
and
(select value from qenddate)
and businesstype = (select value from busstype)
group by business, numberofdeposits,depositamount;

Join between a sqlsever table and an oracle table

I have been using SQL Server 2008 for a short time now and have never used Oracle before. I am able to access an Oracle table through SQL Server with the syntax
select * from [OracleDB1]..[OracleDB1].[Zips]
(where OracleDB1 is the oracle database and Zips is the table I require)
Is it possible to join a SQL Server table with this one in a Table-valued Function? Just using a normal join as I would with SQL Server tables gives an Invalid object name error on the Oracle table.
Can this be done directly (or at all) or is it possible to do this some other way such as table variables?
example query:
select * from dbo.Table1 t INNER JOIN [OracleDB1]..[OracleDB1].[Zips] z where t.zip = z.zip
I was performing the join wrong since I missed the ON clause. I was able to get it to work by declaring a temptable and joining on that.
declare #tempTable table{
ZIP nvarchar(5),
COUNTY nvarchar(10)
}
insert #tempTable select ZIP, COUNTY, from [OracleDB1]..[OracleDB1].[ZIPS]
select * from dbo.Table1 t INNER JOIN #tempTable z on t.ZIP = v.ZIP where t.AdmissionOn >= '08-08-2011' AND t.AdmissionOn <= ''09-08-2011'
This also worked in line as I had in the original question once I added the ON clause but the table variable suits my needs better since it only has to access the Oracle table once and not each comparison.

Oracle Select Query, Order By + Limit Results

I am new to Oracle and working with a fairly large database. I would like to perform a query that will select the desired columns, order by a certain column and also limit the results. According to everything I have read, the below query should be working but it is returning "ORA-00918: column ambiguously defined":
SELECT * FROM(SELECT * FROM EAI.EAI_EVENT_LOG e,
EAI.EAI_EVENT_LOG_MESSAGE e1 WHERE e.SOURCE_URL LIKE '%.XML'
ORDER BY e.REQUEST_DATE_TIME DESC) WHERE ROWNUM <= 20
Any suggestions would be greatly appreciated :D
The error message means your result set contains two columns with the same name. Each column in a query's projection needs to have a unique name. Presumably you have a column (or columns) with the same name in both EAI_EVENT_LOG and EAI_EVENT_LOG_MESSAGE.
You also want to join on that column. At the moment you are generating a cross join between the two tables. In other words, if you have a hundred records in EAI_EVENT_LOG and two hundred records EAI_EVENT_LOG_MESSAGE your result set will be twenty thousand records (without the rownum). This is probably your intention.
"By switching to innerjoin, will that eliminate the error with the
current code?"
No, you'll still need to handle having two columns with the same name. Basically this comes from using SELECT * on two multiple tables. SELECT * is bad practice. It's convenient but it is always better to specify the exact columns you want in the query's projection. That way you can include (say) e.TRANSACTION_ID and exclude e1.TRANSACTION_ID, and avoid the ORA-00918 exception.
Maybe you have some columns in both EAI_EVENT_LOG and EAI_EVENT_LOG_MESSAGE tables having identical names? Instead of SELECT * list all columns you want to select.
Other problem I see is that you are selecting from two tables but you're not joining them in the WHERE clause hence the result set will be the cross product of those two table.
You need to stop using SQL '89 implicit join syntax.
Not because it doesn't work, but because it is evil.
Right now you have a cross join which in 99,9% of the cases is not what you want.
Also every sub-select needs to have it's own alias.
SELECT * FROM
(SELECT e.*, e1.* FROM EAI.EAI_EVENT_LOG e
INNER JOIN EAI.EAI_EVENT_LOG_MESSAGE e1 on (......)
WHERE e.SOURCE_URL LIKE '%.XML'
ORDER BY e.REQUEST_DATE_TIME DESC) s WHERE ROWNUM <= 20
Please specify a join criterion on the dotted line.
Normally you do a join on a keyfield e.g. ON (e.id = e1.event_id)
It's bad idea to use select *, it's better to specify exactly which fields you want:
SELECT e.field1 as customer_id
,e.field2 as customer_name
.....

Table Join Efficiency Question

When joining across tables (as in the examples below), is there an efficiency difference between joining on the tables or joining subqueries containing only the needed columns?
In other words, is there a difference in efficiency between these two tables?
SELECT result
FROM result_tbl
JOIN test_tbl USING (test_id)
JOIN sample_tbl USING (sample_id)
JOIN (SELECT request_id
FROM request_tbl
WHERE request_status='A') USING(request_id)
vs
SELECT result
FROM (SELECT result, test_id FROM result_tbl)
JOIN (SELECT test_id, sample_id FROM test_tbl) USING(test_id)
JOIN (SELECT sample_id FROM sample_tbl) USING(sample_id)
JOIN (SELECT request_id
FROM request_tbl
WHERE request_status='A') USING(request_id)
The only way to find out for sure is to run both with tracing turned on and then look at the trace file. But in all probability they will be treated the same: the optimizer will merge all the inline views into the main statement and come up with the same query plan.
It doesn't matter. It may actually be WORSE since you are taking control away from the optimizer which generally knows best.
However, remember if you are doing a JOIN and only including a column from one of the tables that it is QUITE OFTEN better to re-write it as a series of EXISTS statements -- because that's what you really mean. JOINs (with some exceptions) will join matching rows which is a lot more work for the optimizer to do.
e.g.
SELECT t1.id1
FROM table1 t1
INNER JOIN table2 ON something = something
should almost always be
SELECT id1
FROM table1 t1
WHERE EXISTS( SELECT *
FROM table2
WHERE something = something )
For simple queries the optimizer may reduce the query plans into identical ones. Check it out on your DBMS.
Also this is a code smell and probably should be changed:
JOIN (SELECT request_id
FROM request_tbl
WHERE request_status='A')
to
SELECT result
FROM request
WHERE EXISTS(...)
AND request_status = 'A'
No difference.
You can tell by running EXPLAIN PLAN on both those statements - Oracle knows that all you want is the "result" column, so it only does the minimum necessary to get the data it needs - you should find that the plans will be identical.
The Oracle optimiser does, sometimes, "materialize" a subquery (i.e. run the subquery and keep the results in memory for later reuse), but this is rare and only occurs when the optimiser believes this will result in a performance improvement; in any case, Oracle will do this "materialization" whether you specified the columns in the subqueries or not.
Obviously if the only place the "results" column is stored is in the blocks (along with the rest of the data), Oracle has to visit those blocks - but it will only keep the relevant info (the "result" column and other relevant columns, e.g. "test_id") in memory when processing the query.

Resources