Request your expert opinions -- 9i join syntax?

Are you who do SQL programming going to use the new 9i JOIN syntax? Is the old syntax (using the + sign) going to be depricated soon? What do you think? Why should I switch to the new format? I am wondering what others are doing or planning to do.
Thank you very much for your time.

Personally, I think the ANSI compliant syntax is clearer and easier to read. Also it has FULL OUTER which is something the old Oracle syntax doesn't support.
However, I don't think (+) will be deprecated before 10i and I think it will remained suppported for the foreseeable future: there're just too many lines of SQL code out there using it!
my tuppence halfpenny worth, APC

Similar Messages

OBIEE not applying outer join syntax to filters

(Note: I've already thoroughly searched the forums before posting this. Thanks)
My problem is the following:
I'm trying to build a report that is a count from my fact table, grouped by month from my date dimension for a given year, resulting in 12 data points. The problem is that not all months have actual data, but I still need those months to show on the report with a count of zero. Typical simple reporting requirement.
I have already done the obvious and within my business layer made the join between my fact table and my date dimension an outer join on the fact side, just like you'd do if writing the query by hand. And when tested by hand this includes all dates for the year anyway, and when coupled with the appropriate null test on the count measure I'd get my 12 data points with zeros were appropriate.
The problem is that there are additional filters I need to apply on the fact data (there are a couple text-based code values that didn't warrant full tables themselves so are just degenerate dimensions directly on the fact table.)
When these filters are applied at the Answer level, I'm only getting back the months that actually have data, and lose the months where the count should be zero. A check of the session log for the query that was generated shows the problem. While OBI properly generates the outer-join syntax for the join itself between the two tables (my date dim and fact table) it does NOT apply the outer-syntax to the constant-based filter against the fact, effectively negating the outer join.
Actual query from the log (I simply changed the table aliases from the ugly T##### stuff OBI generates to something more readable for posting here):
select D.DT_MONTH_NAME as c1,
D.DT_MONTH_NUM as c2,
I.INC_TYPE as c3,
I.INC_EMP_GROUP as c4,
sum(case when I.INC_KEY is null then 0 else 1 end ) as c5
from DATE_DIM D, INCIDENT_F I
where ( D.DATE_KEY = I.DATE_KEY (+) ) and ( D.DT_YEAR = 2010 and I.INC_EMP_GROUP = 'CONTRACTOR' )
group by D.DT_MONTH_NUM, D.DT_MONTH_NAME, I.INC_TYPE, I.INC_EMP_GROUP
order by c2
You can see that the outer syntax (+) is applied to the join, but not to the filter on I.INC_EMP_GROUP. If I take this query and drop it in something like SQL Developer, it only returns the months with data. If I throw the (+) after I.INC_EMP_GROUP like I'd do if writing this by hand, the desired zero-months results pop back in.
I have already searched the forums and while lots of people seem to have asked this question, the only solutions involve things like trickery in the business layer using dummy fact tables followed by manipulations at the report level etc. Unfortunately I can't rely on these as the system is eventually to be turned over to users who can't be expected to apply various hacks to write reports.
Anyone ever get to the bottom of getting OBI to apply outer join logic in filters as well, when the filtered table is meant to be outer-joined to?
Any comments are appreciated.
John

I know that this thread is a bit old thought it might be helpful to some one...
The Issue is, when using Degener@teDimen$ion ( this is !nner joned to FACT tables in BMM) and if any of the dimensions {other than theDegener@teDimen$ion (Let us say Dim X) } have an ()uter join to any of the fact tables, and you were doing your analysis using Degener@teDimen$ion, Dim X, Measure value you will face the following issues.
when filtering the analysis on the ()uter join dimension ( Dim X), the IN filter will not work. Reason is that the filter is getting applied to both the Dimension and FACT tables and the values that exist in Dimension Dim X but not in FACT table wont show up.
The above issue can be fixed by changing the join between the fact and Degener@teDimen$ion from inner to outer. I think this is a bug.. because it is supposed to filter the fact table after the entire outer joined result is obtained but not filter the fact table for the Dim X values and do a outer join. I think the BI should be intelligent enough.

Outer Join Syntax in sql2k to Oracle Migration

All of my existing SQL Server 2000 code is using the (INNER, LEFT OUTER, RIGHT OUTER) JOIN syntax which according to Oracle SQL Reference (A90125-01) is supported. The migration workbench seems to want to convert this to the old style syntax of putting (+) in the where clause conditions. I am therefore getting lots of warnings telling me that "complex outer joins are not reliably supported". Is there a setting somewhere that will tell the migration workbench to maintain (subject to required conversion) the original syntax format.

Hi Doug,
The issue you report has been tackled in a recent internal build released by the OMWB team. OMWB version 9.2.0.1.6 which is freely downloadable on the http:\\mtg.ie.oracle.com site. As I've mentioned, this is an internal release and is therefore not supported - although it is very stable and has already been used by several internal customers. We expect to have a fully supported release of OMWB available on OTN in December.
In version 9.2.0.1.6, there is an option in the "Parse Options" tab on the Stored Procedures property sheet called "Generate Oracle 8i Outer Joins" - this setting is switched off by default in this build and would therefore preserve your ANSI compliant joins by default. Switching the setting on causes the OMWB parser to generate the joins in the old (+) Oracle syntax standard.
I hope this helps,
Tom.

Difference between oracle join syntaxes and ANSI join syntaxes

What is difference between oracle join syntaxes and ANSI join syntaxes ?
why oracle is having different syntaxes for joins than ANSI syntaxes ?
Also Join syntaxes are different in some oracle vesrions ?

BluShadow wrote:
3360 wrote:
Yes it is. The Oracle database wasn't initially designed to be ANSI compliant. As you correctly state the ANSI standards weren't around when it was initially designed, so the statement is perfectly correct. ;)Ok, in one sense it may be correct but it is a completely misleading statement. Not sure why you think it's misleading.Because there was no ANSI standard, so making it sound like a design choice The Oracle database wasn't initially designed to be ANSI compliant. would suggest to most readers that there was a standard to be compliant to.
Like saying Ford originally did not design their cars to incorporate safety features such as ABS, seat belts and air bags.
The OP asked "why oracle is having different syntaxes for joins than ANSI syntaxes ?" and the answer is that Oracle wasn't initially designed with ANSI compliance, so it has it's old non-ANSI syntax,As shown above, the old syntax was ANSI compliant at the time and to call it non-ANSI is either incorrect or misleading dependent on your point of view.
and since ANSI syntax became the standard it now supports that. And since ANSI switched to a new standard, Oracle had to implement the new standard as well as the previous ANSI standard would be more accurate in my opinion.
Nothing misleading as far as I'm aware in that.I find the whole discussion about ANSI and Oracle's supposed non-compliance, reads like it was Oracle's choice to deviate from the standards, when it was ANSI's bullheaded decisions to pointlessly change standards that left Oracle and other vendors out of compliance, and that was a decision made solely by ANSI.
This is probably the reason ANSI no longer produces SQL standards, the endless syntax fiddling would eventually have made forward left under outer joins a reality.
{message:id=1785128}

Drag-n-n-drop query joins uses WHERE, not INNER JOIN syntax

When I highlight a few tables and drag them onto the sql worksheet, it will build a select statement for me and join the tables by their foreign keys.
That's a nice feature, thanks!
Three questions. Is it possible to:
1. get it to use the INNER JOIN and LEFT OUTER JOIN syntax instead of joining the tables in the WHERE clause?
2. control the table aliases so that it will automatically use the "standard alias" for the table instead of A, B, C, etc.?
3. get it to not put the schema name into the query?
Thanks!
Edited by: David Wendelken on Nov 22, 2008 1:48 PM. Grammar mistake.

Hi Gopi,
Your code is Good.
But try to avoid Inner join with more number of Tables ...because this is a performance issue..
try to use..
select (primary key fields mainly,other fields) from LIKP into itab where bolnr in p_bolnr(paramater).
next try to use for all entries option..
select (primary key fields mainly,other fields) from VBFA for all entries in itab where (give the condition)....
simillarly do for the other select ....ok this will try to reduce the performance issue....
<b><REMOVED BY MODERATOR></b>
Message was edited by:
Alvaro Tejada Galindo

I need your expert opinion on how to create a map with multiple conditions.

Hello.
I need your expert opinion on how to create a map with multiple conditions.
I have a procedure (which i cannot import or re-create in OWB due to the bug), so i am trying to create a map instead :-(
How can i create a cursors within the map?
My function creates table and cursor.
Then it will have to check for duplicates in the tables (the one created and another table) - the criteria for finding duplicates is a number of fields.I then need to place few different conditions (if some attributes are not available) and it has to load cursor based on this conditions. The next step is to fetch the data into the cursor based on what attributes are missing.
The next thing it will do is insert the data into table (if record doesn't exist), output the error in separate table is record is corrupted, or update the record with changed information.
In short i need to re-create match / merge but with conditions, iterations etc 'built into' it.
I can read up on available functions - it's just what would be the best options? and what would be the best approach to do so?
In my function i use %rowtype - but cannot use it in owb - so what would be the alternative? i don't really want to create a lot of variables and then have a nightmare of maintaing it. are there any tips regarding this?
having looked through Oracle dedupe - it's not really what i need because it is just DISTINCT.
I would appreciate any help / advise on this.
Thank you very much

thanks a lot for your reply - i will look into this option :-)
it is a bit more complicated now as i have to re-create the match / merge and then somehow 'tweak' it to achieve the result i need.
At the moment i am looking to breakdown the package into smaller chunks 'functions' and try creating the map that way.
Anyway, thank you very much for your suggestion.

SRM: Extended Classic scenario: Request your help.

Hi Guru's,
We are implementing the EXTENDED CLASSIC SCENARIO in our project. kindly request your help.
in our project the SRM box is : G3OSBSR102.
R/3 backend Box is : RCHSBR3142.
Now when i create a shopping cart it should create the Purchase order In SRM( G3OSBSR102) and also copy the created purcahse order in teh backend system : RCHSBR3142.
The issue here is which Logical system should be populated in the field at item level when creating the shopping cart :BE_LOG_SYSTEM.
1) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: G3OSBSR102., then it will consider the Business object type as : BUS2201and creates the local Po but while transfering this local created document(PO) to R/3 system is loosing the Logical system at the item level of the PO.
If i populate this field at the item level via DEBUGG mode then system is sucessfull in transferring the document to R/3.
2) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: RCHSBR3142, then it will consider the Business object type as : BUS2012 and creates the purchase order in R/3 system and will not create teh local purchase order.
Kindly request your help for any further settings if i did miss.Appreciate your help in this regards.
Many Thanks,
Prasad NN.

Dear Prasad,
To work on Extended Classic Scenario, you just have to maintain the following configuration in SPRO:
>SAP Supplier Relationship Management
>SRM Server
>Cross-Application Basic Settings
>Activate Extended Classic Scenario
Check the flag "Extended Classic Scenario Active".
You dont have to manipulate "BE_LOG_SYSTEM" field to choose your scenario.
Regards
Thiago Salvador

SR_ Extended Classic Scenario : Request your help please

Hi Guru's,
We are implementing the EXTENDED CLASSIC SCENARIO in our project. kindly request your help.
in our project the SRM box is : G3OSBSR102.
R/3 backend Box is : RCHSBR3142.
Now when i create a shopping cart it should create the Purchase order In SRM( G3OSBSR102) and also copy the created purcahse order in teh backend system : RCHSBR3142.
The issue here is which Logical system should be populated in the field at item level when creating the shopping cart :BE_LOG_SYSTEM.
1) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: G3OSBSR102., then it will consider the Business object type as : BUS2201and creates the local Po but while transfering this local created document(PO) to R/3 system is loosing the Logical system at the item level of the PO.
If i populate this field at the item level via DEBUGG mode then system is sucessfull in transferring the document to R/3.
2) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: RCHSBR3142, then it will consider the Business object type as : BUS2012 and creates the purchase order in R/3 system and will not create teh local purchase order.
Kindly request your help for any further settings if i did miss.Appreciate your help in this regards.
Many Thanks,
Prasad NN.

Hi ,
Go to SPRO
There is a node - Activate Extended Classic scenario
Do the config.
Regards
G.Ganesh Kumar

Bug in JOIN syntax? (oracle 9i)

Hi,
take these three tables:
MASTER (id NUMBER, name VARCHAR2(10))
DETAIL (id NUMBER, master_id NUMBER)
SUBDETAIL (id NUMBER, detail_id NUMBER, name VARCHAR(10)
When I perform this query:
SELECT SUBDETAIL.id as did, MASTER.id as mid
FROM SUBDETAIL
JOIN DETAIL ON (SUBDETAIL.detail_id = DETAIL.id)
JOIN MASTER ON (DETAIL.master_id = MASTER.id)
WHERE
name = 'joe';
I would expect the parser to give me 'column ambiguously defined' (because the 'name' field from the whereclause is defined in both subdetail and master).
However, it does not say that. Instead, it assumes that it should use the name field from master. This is confusing, as this could easily lead to mistakes (as it did in my application)
Greetings,
Ivo

There seems to be a difference between the way Oracle resolves column names using the ANSI join syntax and Oracle's syntax. It appears that Oracle does not know about the columns, until it processes each join, and further, the last table joined seems to be sued to resolve nameing conflicts. Consider:
SQL> SELECT * FROM master;
        ID NAME
         1 joe
SQL> SELECT * FROM subdetail;
        ID DETAIL_ID NAME
         1          2 fred
SQL> SELECT * FROM detail;
        ID MASTER_ID
         2          1
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM subdetail
3       JOIN detail ON (subdetail.detail_id = detail.id)
4       JOIN master ON (detail.master_id = master.id)
5 WHERE name = 'joe';
       DID        MID
         1          1
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM subdetail
3       JOIN detail ON (subdetail.detail_id = detail.id)
4       JOIN master ON (detail.master_id = master.id)
5 WHERE name = 'fred';
no rows selected
So, it is clearly going after master.name. However,
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM detail
3       JOIN master ON (master.id = master_id)
4       JOIN subdetail ON (subdetail.detail_id = detail.id)
5 WHERE name = 'joe'
no rows selected
But,
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM detail
3       JOIN subdetail ON (subdetail.detail_id = detail.id)
4       JOIN master ON (master.id = master_id)
5 WHERE name = 'joe'
       DID        MID
         1          1
Old style syntax gives:
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM subdetail, detail, master
3 WHERE subdetail.detail_id = detail.id and
4        detail.master_id = master.id and
5        name = 'joe';
      name = 'joe'
ERROR at line 5:
ORA-00918: column ambiguously defined
and note that
SQL> SELECT subdetail.id AS did, master.id AS mid
2 FROM subdetail
3      JOIN master ON (detail.master_id = master.id)
4      JOIN detail ON (subdetail.detail_id = detail.id)
5 WHERE name = 'joe'
    JOIN master ON (detail.master_id = master.id)
ERROR at line 3:
ORA-00904: invalid column nameSo, in ANSI syntax, order matters, and whatever the syntax good testing matters.
TTFN
John

Flow accept error when using ANSI join syntax

Hi
I had a region populated by a query joining two views (one in-line using connect by). When trying to create the region if the join was coded using ANSI syntax (INNER JOIN .... USING) I got a flow accept error when either trying to proceed using the wizard, or apply changes when editing the region.
After changing to the old style Oracle join (using predicates), I was able to create the region and everything worked ok. I found the solution after reading this post Error 404 wwv_flow.accept was not found in which the OP says he would raise a bug. Did the bug get raised? I ask since his problem arose whilst he was selecting from a view using ANSI joins and using instead of triggers, and I was joining an in-line view to a view using ANSI joins and instead of triggers, but neither view has been changed, just the join syntax. The view defined in the database is used in other regions and works fine. This could indicate the OP's problem was fixed, but one still exists.
Incidentally this is the only time I have used non-ANSI joins in the entire apex app - the rest work!. Unfortunately it is impossible for me to demo the app.
Richard
using ApEx 3.0.1.00.07 and 10g (10.2.0.1) EE on Wintel

Tyler,
Apologies, what I was trying to say was that I couldn't put the application on the Oracle APEX site.
Yes, I do have a work-around, but that does not mean a bug may still exist. I count myself fortunate I saw that post and, therefore, experimented with the syntax of the join - there is no reason APEX should not accept ANSI join conditions, in fact , it does. The ANSI-joined SQL statement executed perfectly in TOAD and SQL*Plus, but I could not even save it in APEX.
regards
Richard

"use ODBC outer join syntax on limits" issues

I'm converting a series of BQY's from Brio 6.6 to Hyperion 9.3. I have some questions about the "use ODBC outer join syntax on limits" option in the OCE. I sort of understand this option's purpose, but I don't completely understand the SQL I'm seeing. For example Brio 6.6 is generating the following SQL statement:
SELECT * FROM tblA AL1 LEFT OUTER JOIN tblB AL38 ON (AL38.ParentID=AL1.ChildID AND
AL38.Data='SomeData') WHERE ((NOT AL38.Action IS NULL))
Now, Hyperion 9.3 generated the SQL statement as follows:
SELECT * FROM tblA AL1 LEFT OUTER JOIN tblB AL38 ON (AL38.ParentID=AL1.ChildID AND
AL38.Data='SomeData') AND (NOT AL38.Response IS NULL))
My questions are:
1) Why isn't the "NOT AL38.Action IS NULL" statement included in the outer join in Brio? I'm OK with the fact that it is not, but my limited understanding of the "use ODBC outer join syntax on limits" seems to indicate that it should end up there.
2) The Hyperion SQL is returning incorrect results. How can I get Hyperion to generate the same SQL as Brio? And still use the OCE with "use ODBC outer join syntax on limits" selected? This setting is working fine for other BQY's.

In the first post, I modified the actual table name I'm using, the following is my actual output:
SQL> SELECT A0.name partName,A2.name usedPartName FROM WTPartUsageLink A1
2 RIGHT OUTER JOIN (
3 (SELECT A0.idA2A2,A0B.name FROM WTPart A0 INNER JOIN WTPartMaster A0B
4 ON ((A0.idA3masterReference = A0B.idA2A2)))
5 UNION ALL
6 (SELECT A0.idA2A2,A0B.name
7 FROM WTProduct A0 INNER JOIN WTProductMaster A0B ON ((A0.idA3masterRefer
ence = A0B.idA2A2)))) A0
8 ON (A0.idA2A2 = A1.idA3A5) LEFT OUTER JOIN
9 (SELECT A2.idA2A2,A2.name FROM WTPartMaster A2
10 UNION ALL
11 SELECT A2.idA2A2,A2.name FROM WTProductMaster A2) A2
12 ON (A1.idA3B5 = A2.idA2A2) ORDER BY partName DESC,usedPartName DESC;
FROM WTProduct A0 INNER JOIN WTProductMaster A0B ON ((A0.idA3masterRefer
ence = A0B.idA2A2)))) A0
ERROR at line 7:
ORA-00923: FROM keyword not found where expected
SQL> select * from v$version;
BANNER
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
PL/SQL Release 9.2.0.1.0 - Production
CORE 9.2.0.1.0 Production
TNS for Solaris: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production
Thanks,

Old outer join syntax produces different results from new syntax!

I have inherited a query that uses the old outer join syntax but that is yielding correct results. When I translate it to the new outer join syntax, I get the results I expect, but they are not correct! And I don't understand why the old syntax produces the results it produces. Bottom line: I want the results I'm getting from the old syntax, but I need it in the new syntax (I'm putting it into Reporting Services, and RS automatically converts old syntax to new).
Here's the query with the old outer join syntax that is working correctly:
Code Snippet
SELECT   TE = COUNT(DISTINCT T1.ID),
         UE = COUNT(DISTINCT T2.ID),
         PE = CONVERT(MONEY, COUNT(DISTINCT T2.ID)) /
              CONVERT(MONEY,COUNT(DISTINCT T1.ID))
FROM     TABLE T1, TABLE T2
WHERE    T1 *= T2
In this query, much to my surprise, TE <> UE and PE <> 1. However, TE, UE, and PE seem to be accurate!
Here's the query with the new outer join syntax that is working but not producing the results I need:
Code Snippet
SELECT   TE = COUNT(DISTINCT T1.ID),
         UE = COUNT(DISTINCT T2.ID),
         PE = CONVERT(MONEY, COUNT(DISTINCT T2.ID)) /
              CONVERT(MONEY,COUNT(DISTINCT T1.ID))
FROM     TABLE T1 LEFT OUTER JOIN TABLE T2 ON T1.ID = T2.ID
Though not producing the results I need, it is producing what would be expected: TE = UE and PE = 1.
My questions:
1) Can someone who is familiar enough with the old syntax please help me understand why TE <> UE and PE <> 1 in the first query?
2) Can someone please tell me how to properly translate the first query to the new syntax so that it continues to produce the results in the first query?
Thank you very much.

How can we reproduce the issue?
Code Snippet
USE [master]
GO
EXEC sp_dbcmptlevel Northwind, 80
GO
USE [Northwind]
GO
SELECT
TE
= COUNT(DISTINCT T1.OrderID),
UE = COUNT(DISTINCT T2.OrderID),
PE = CONVERT(MONEY, COUNT(DISTINCT T2.OrderID)) /
CONVERT(MONEY,COUNT(DISTINCT T1.OrderID))
FROM
dbo
.Orders T1, dbo.Orders T2
WHERE
T1
.OrderID *= T2.OrderID
SELECT
TE
= COUNT(DISTINCT T1.OrderID),
UE = COUNT(DISTINCT T2.OrderID),
PE = CONVERT(MONEY, COUNT(DISTINCT T2.OrderID)) /
CONVERT(MONEY,COUNT(DISTINCT T1.OrderID))
FROM
dbo
.Orders T1
LEFT OUTER JOIN
dbo.Orders T2
ON T1.OrderID = T2.OrderID
GO
EXEC sp_dbcmptlevel Northwind, 90
GO
Result:
TE
UE
PE
830
830
1.00
TE
UE
PE
830
830
1.00
As you can see, I am getting same results.
AMB

ANSI/9i Join Syntax and Pretty Code

I've always tried to keep my SQL statement code formatted in a way that I think helps readability. I picked up the following style because I found it easy to quickly find the FROM clause and the JOINS or conditions:
select e.ename,
       e.sal,
       d.dname
from   emp e,
       dept d
   * Joins
where e.deptno = d.deptno
   * Conditions
and    d.dname = 'SALES'
/Of course, for such a simple query I wouldn't have used the comments to divide the WHERE clause into joins and conditions...
Anyway, since Tom Kyte and the 9i documentation suggest using the ANSI join syntax (amongst other reasons), I have decided to begin changing my ways. However, I am having troubles figuring out how to format my SQL to still be "pretty."
For the previous example, a new formatting style seems easy:
select e.ename,
       e.sal,
       d.dname
from   emp e
join dept d          on e.deptno = d.deptno
where d.dname = 'SALES'
/Now, when we use an example that has optional joins is where I can't figure what my style should be:
select e.ename,
       m.ename as manager
from        emp e
left join emp m      on e.mgr = m.empno
where e.deptno = 10
/I don't really like this style since it gets so wide, causing problems when indenting for subqueries/inline-views. It also looks kinda clunky because the tables are indented more than everything else...
Anyway, since I don't want to spend a bunch of time figuring out things like style, I'd like to see what other formats people are using. I'd appreciate seeing how others are formatting thier SQL when using the new 9i (old-ANSI) syntax.
Thanks, Stan

That looks to me like left aligned (but I may be on the wrong side of the looking glass...)
By preference is to left-align the KEYWORDS and the data words, using indentation to distinguish the start of the different clauses (SELECT, FROM, WHERE, ORDER BY, etc.). This approach is easily standardised with Textpad or similar editing tools. Quite how one programs a text editor to turn one's code into a Rorschach blot is beyond me.
I haven't done much with ANSI joins, so I hadn't come up with a standard for layout. The following is what I think I would do if I ever had to, and is basically an adaption of what I do now ...
FROM   user_indexes i
       , user_ind_columns ic2
       , user_tab_columns c2with the ANSI join stuff indented and aligned. I find rigourous application of UPPER and lower case tends to assist clarity: indentation and alignment are not enough.
SELECT i.table_name
       , i.index_name
       , ic2.column_position
FROM   user_indexes i
       INNER JOIN user_ind_columns ic2
       ON i.table_name = ic2.table_name
       AND i.index_name = ic2.index_name
       INNER JOIN user_tab_columns c2
       ON ic2.table_name = c2.table_name
       AND ic2.column_name = c2.column_name
WHERE i.uniqueness='UNIQUE'
ORDER BY i.table_name
       , i.index_name
       , ic2.column_position
/

In your guys' opinions, which is better? iPhone 5c or iPhone 5s?

In your guys' opinions, which is better? iPhone 5c or iPhone 5s?

Definitely iPhone 5s, as it has the new A7 chip while the iPhone 5c is the same as iPhone 5 with just a fancy case. Well apart from that there is no much big difference, however the iPhone 5c is much cheaper if your looking at it price wise. So depending on what you want.
Check more details on http://www.apple.com/iphone/compare/

Use ansi join syntax

From what i have been reading is better to use the new syntax(dont know how new it is)

The ANSI join syntax was new to Oracle in Oracle 8i in 1998 - that's 15 years old.
It can produce more readable code, and is both more readable and less human-error prone for outer joins.
The ANSI format lets you outer join between multiple tables in a way the old oracle-specific ( + ) syntax did not and introduces FULL OUTER JOIN which you should use very rarely.
You should not use NATURAL JOIN in code - adding unrelated columns to the tables involved can make it give very different results.
There have not been significant bugs for ANSI joins in Oracle since Oracle 10.2 was introduced about 8 years ago.
As Paul said, the ON part should be the join criteria between the tables. The were clause should be the filtering of the joined tables.
So assuming start_date, end_date and in_property_id are variables
SELECT resv_num, unit_date
    FROM p_resv_unit ru
    INNER JOIN p_pm_unit_night pun
    ON pun.resv_unit_id = ru.resv_unit_id
    WHERE pun.property_id = in_property_id
    AND pun.unit_date BETWEEN start_date AND end_date
    AND pun.pm_unit_num = cvUnitNum;
If start_date and end_date were columns in p_resv_unit the query would be:
SELECT resv_num, unit_date
    FROM p_resv_unit ru
    INNER JOIN p_pm_unit_night pun
    ON pun.resv_unit_id = ru.resv_unit_id AND pun.unit_date BETWEEN ru.start_date AND ru.end_date
    WHERE pun.property_id = in_property_id
        AND pun.pm_unit_num = cvUnitNum;
Inner join queries work with criteria in the wrong place, but they're harder to read. Outer joins don't work unless you put the criteria in the right place.

Request your expert opinions -- 9i join syntax?

Similar Messages

Maybe you are looking for