EJBQL join syntax example

Some sample EJBQL:
select distinct t1 from Table1 t1 join Table2 t2 where t1.col1 = t2.col2
Is there any syntactic reason why this should not work? I'm struggling to get a join working and I can't find any good examples of the correct syntax.
many thanks
R

To perform a join, the collection has to exist in the entity? So, a collection of Table2's would need to be in Table1?

Similar Messages

"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,

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
/

All Joins with Example

Hi Experts,
Pls let me know what are all joins available in ABAP??
One example program for each for better understanding...
Any useful inputs on this will be highly rewarded.
Thanks in advance
Rgds ~ Lakshmiraj

Hi,
Joins are used to fetch data fast from Database tables:
Tables are joined with the proper key fields to fetch the data properly.
If there are no proper key fields between tables don't use Joins;
Important thing is that don't USE JOINS FOR CLUSTER tableslike BSEG and KONV.
Only use for Transparenmt tables.
You can also use joins for the database VIews to fetch the data.
JOINS
... FROM tabref1 [INNER] JOIN tabref2 ON cond
Effect
The data is to be selected from transparent database tables and/or views determined by tabref1 and tabref2. tabref1 and tabref2 each have the same form as in variant 1 or are themselves Join expressions. The keyword INNER does not have to be specified. The database tables or views determined by tabref1 and tabref2 must be recognized by the ABAP Dictionary.
In a relational data structure, it is quite normal for data that belongs together to be split up across several tables to help the process of standardization (see relational databases). To regroup this information into a database query, you can link tables using the join command. This formulates conditions for the columns in the tables involved. The inner join contains all combinations of lines from the database table determined by tabref1 with lines from the table determined by tabref2, whose values together meet the logical condition (join condition) specified using ON>cond.
Inner join between table 1 and table 2, where column D in both tables in the join condition is set the same:
Table 1 Table 2
A
B
C
D
D
E
F
G
H
a1
b1
c1
1
1
e1
f1
g1
h1
a2
b2
c2
1
3
e2
f2
g2
h2
a3
b3
c3
2
4
e3
f3
g3
h3
a4
b4
c4
3
|--|||--|
Inner Join
A
B
C
D
D
E
F
G
H
a1
b1
c1
1
1
e1
f1
g1
h1
a2
b2
c2
1
1
e1
f1
g1
h1
a4
b4
c4
3
3
e2
f2
g2
h2
|--||||||||--|
Example
Output a list of all flights from Frankfurt to New York between September 10th and 20th, 2001 that are not sold out:
DATA: DATE LIKE SFLIGHT-FLDATE,
CARRID LIKE SFLIGHT-CARRID,
CONNID LIKE SFLIGHT-CONNID.
SELECT FCARRID FCONNID F~FLDATE
INTO (CARRID, CONNID, DATE)
FROM SFLIGHT AS F INNER JOIN SPFLI AS P
ON FCARRID = PCARRID AND
FCONNID = PCONNID
WHERE P~CITYFROM = 'FRANKFURT'
AND P~CITYTO = 'NEW YORK'
AND F~FLDATE BETWEEN '20010910' AND '20010920'
AND FSEATSOCC < FSEATSMAX.
WRITE: / DATE, CARRID, CONNID.
ENDSELECT.
If there are columns with the same name in both tables, you must distinguish between them by prefixing the field descriptor with the table name or a table alias.
Note
In order to determine the result of a SELECT command where the FROM clause contains a join, the database system first creates a temporary table containing the lines that meet the ON condition. The WHERE condition is then applied to the temporary table. It does not matter in an inner join whether the condition is in the ON or WHEREclause. The following example returns the same solution as the previous one.
Example
Output of a list of all flights from Frankfurt to New York between September 10th and 20th, 2001 that are not sold out:
DATA: DATE LIKE SFLIGHT-FLDATE,
CARRID LIKE SFLIGHT-CARRID,
CONNID LIKE SFLIGHT-CONNID.
SELECT FCARRID FCONNID F~FLDATE
INTO (CARRID, CONNID, DATE)
FROM SFLIGHT AS F INNER JOIN SPFLI AS P
ON FCARRID = PCARRID
WHERE FCONNID = PCONNID
AND P~CITYFROM = 'FRANKFURT'
AND P~CITYTO = 'NEW YORK'
AND F~FLDATE BETWEEN '20010910' AND '20010920'
AND FSEATSOCC < FSEATSMAX.
WRITE: / DATE, CARRID, CONNID.
ENDSELECT.
Note
Since not all of the database systems supported by SAP use the standard syntax for ON conditions, the syntax has been restricted. It only allows those joins that produce the same results on all of the supported database systems:
Only a table or view may appear to the right of the JOIN operator, not another join expression.
Only AND is possible in the ON condition as a logical operator.
Each comparison in the ON condition must contain a field from the right-hand table.
If an outer join occurs in the FROM clause, all the ON conditions must contain at least one "real" JOIN condition (a condition that contains a field from tabref1 amd a field from tabref2.
Note
In some cases, '*' may be specified in the SELECT clause, and an internal table or work area is entered into the INTO clause (instead of a list of fields). If so, the fields are written to the target area from left to right in the order in which the tables appear in the FROM clause, according to the structure of each table work area. There can then be gaps between table work areas if you use an Alignment Request. For this reason, you should define the target work area with reference to the types of the database tables, not simply by counting the total number of fields. For an example, see below:
Variant 3
... FROM tabref1 LEFT [OUTER] JOIN tabref2 ON cond
Effect
Selects the data from the transparent database tables and/or views specified in tabref1 and tabref2. tabref1 und tabref2 both have either the same form as in variant 1 or are themselves join expressions. The keyword OUTER can be omitted. The database tables or views specified in tabref1 and tabref2 must be recognized by the ABAP-Dictionary.
In order to determine the result of a SELECT command where the FROM clause contains a left outer join, the database system creates a temporary table containing the lines that meet the ON condition. The remaining fields from the left-hand table (tabref1) are then added to this table, and their corresponding fields from the right-hand table are filled with ZERO values. The system then applies the WHERE condition to the table.
Left outer join between table 1 and table 2 where column D in both tables set the join condition:
Table 1 Table 2
A
B
C
D
D
E
F
G
H
a1
b1
c1
1
1
e1
f1
g1
h1
a2
b2
c2
1
3
e2
f2
g2
h2
a3
b3
c3
2
4
e3
f3
g3
h3
a4
b4
c4
3
|--|||--|
Left Outer Join
A
B
C
D
D
E
F
G
H
a1
b1
c1
1
1
e1
f1
g1
h1
a2
b2
c2
1
1
e1
f1
g1
h1
a3
b3
c3
2
NULL
NULL
NULL
NULL
NULL
a4
b4
c4
3
3
e2
f2
g2
h2
|--||||||||--|
Example
Output a list of all custimers with their bookings for October 15th, 2001:
DATA: CUSTOMER TYPE SCUSTOM,
BOOKING TYPE SBOOK.
SELECT SCUSTOMNAME SCUSTOMPOSTCODE SCUSTOM~CITY
SBOOKFLDATE SBOOKCARRID SBOOKCONNID SBOOKBOOKID
INTO (CUSTOMER-NAME, CUSTOMER-POSTCODE, CUSTOMER-CITY,
BOOKING-FLDATE, BOOKING-CARRID, BOOKING-CONNID,
BOOKING-BOOKID)
FROM SCUSTOM LEFT OUTER JOIN SBOOK
ON SCUSTOMID = SBOOKCUSTOMID AND
SBOOK~FLDATE = '20011015'
ORDER BY SCUSTOMNAME SBOOKFLDATE.
WRITE: / CUSTOMER-NAME, CUSTOMER-POSTCODE, CUSTOMER-CITY,
BOOKING-FLDATE, BOOKING-CARRID, BOOKING-CONNID,
BOOKING-BOOKID.
ENDSELECT.
If there are columns with the same name in both tables, you must distinguish between them by prefixing the field descriptor with the table name or using an alias.
Note
For the resulting set of a SELECT command with a left outer join in the FROM clause, it is generally of crucial importance whether a logical condition is in the ON or WHERE condition. Since not all of the database systems supported by SAP themselves support the standard syntax and semantics of the left outer join, the syntax has been restricted to those cases that return the same solution in all database systems:
Only a table or view may come after the JOIN operator, not another join statement.
The only logical operator allowed in the ON condition is AND.
Each comparison in the ON condition must contain a field from the right-hand table.
Comparisons in the WHERE condition must not contain a field from the right-hand table.
The ON condition must contain at least one "real" JOIN condition (a condition in which a field from tabref1 as well as from tabref2 occurs).
Note
In some cases, '*' may be specivied as the field list in the SELECT clause, and an internal table or work area is entered in the INTO clause (instead of a list of fields). If so, the fields are written to the target area from left to right in the order in which the tables appear in the llen in der FROM clause, according to the structure of each table work area. There can be gaps between the table work areas if you use an Alignment Request. For this reason, you should define the target work area with reference to the types of the database tables, as in the following example (not simply by counting the total number of fields).
Example
Example of a JOIN with more than two tables: Select all flights from Frankfurt to New York between September 10th and 20th, 2001 where there are available places, and display the name of the airline.
DATA: BEGIN OF WA,
FLIGHT TYPE SFLIGHT,
PFLI TYPE SPFLI,
CARR TYPE SCARR,
END OF WA.
SELECT * INTO WA
FROM ( SFLIGHT AS F INNER JOIN SPFLI AS P
ON FCARRID = PCARRID AND
FCONNID = PCONNID )
INNER JOIN SCARR AS C
ON FCARRID = CCARRID
WHERE P~CITYFROM = 'FRANKFURT'
AND P~CITYTO = 'NEW YORK'
AND F~FLDATE BETWEEN '20010910' AND '20010920'
AND FSEATSOCC < FSEATSMAX.
WRITE: / WA-CARR-CARRNAME, WA-FLIGHT-FLDATE, WA-FLIGHT-CARRID,
WA-FLIGHT-CONNID.
ENDSELECT.
Syntax
... [(] {dbtab_left [AS tabalias_left]} | join
{[INNER] JOIN}|{LEFT [OUTER] JOIN}
{dbtab_right [AS tabalias_right] ON join_cond} [)] ... .
Effect
The join syntax represents a recursively nestable join expression. A join expression consists of a left-hand and a right- hand side, which are joined either by means of [INNER] JOIN or LEFT [OUTER] JOIN . Depending on the type of join, a join expression can be either an inner ( INNER) or an outer (LEFT OUTER) join. Every join expression can be enclosed in round brackets. If a join expression is used, the SELECT command circumvents SAP buffering.
On the left-hand side, either a single database table, a view dbtab_left, or a join expression join can be specified. On the right-hand side, a single database table or a view dbtab_right as well as join conditions join_cond can be specified after ON. In this way, a maximum of 24 join expressions that join 25 database tables or views with each other can be specified after FROM.
AS can be used to specify an alternative table name tabalias for each of the specified database table names or for every view. A database table or a view can occur multiple times within a join expression and, in this case, have various alternative names.
The syntax of the join conditions join_cond is the same as that of the sql_cond conditions after the addition WHERE, with the following differences:
At least one comparison must be specified after ON.
Individual comparisons may be joined using AND only.
All comparisons must contain a column in the database table or the view dbtab_right on the right-hand side as an operand.
The following language elements may not be used: BETWEEN, LIKE, IN.
No sub-queries may be used.
For outer joins, only equality comparisons (=, EQ) are possible.
If an outer join occurs after FROM, the join condition of every join expression must contain at least one comparison between columns on the left-hand and the right-hand side.
In outer joins, all comparisons that contain columns as operands in the database table or the view dbtab_right on the right-hand side must be specified in the corresponding join condition. In the WHERE condition of the same SELECT command, these columns are not allowed as operands.
Resulting set for inner join
The inner join joins the columns of every selected line on the left- hand side with the columns of all lines on the right-hand side that jointly fulfil the join_cond condition. A line in the resulting set is created for every such line on the right-hand side. The content of the column on the left-hand side may be duplicated in this case. If none of the lines on the right-hand side fulfils the join_cond condition, no line is created in the resulting set.
Resulting set for outer join
The outer join basically creates the same resulting set as the inner join, with the difference that at least one line is created in the resulting set for every selected line on the left-hand side, even if no line on the right-hand side fulfils the join_cond condition. The columns on the right-hand side that do not fulfil the join_cond condition are filled with null values.
Example
Join the columns carrname, connid, fldate of the database tables scarr, spfli and sflight by means of two inner joins. A list is created of the flights from p_cityfr to p_cityto. Alternative names are used for every table.
PARAMETERS: p_cityfr TYPE spfli-cityfrom,
p_cityto TYPE spfli-cityto.
DATA: BEGIN OF wa,
fldate TYPE sflight-fldate,
carrname TYPE scarr-carrname,
connid TYPE spfli-connid,
END OF wa.
DATA itab LIKE SORTED TABLE OF wa
WITH UNIQUE KEY fldate carrname connid.
SELECT ccarrname pconnid f~fldate
INTO CORRESPONDING FIELDS OF TABLE itab
FROM ( ( scarr AS c
INNER JOIN spfli AS p ON pcarrid = ccarrid
AND p~cityfrom = p_cityfr
AND p~cityto = p_cityto )
INNER JOIN sflight AS f ON fcarrid = pcarrid
AND fconnid = pconnid ).
LOOP AT itab INTO wa.
WRITE: / wa-fldate, wa-carrname, wa-connid.
ENDLOOP.
Example
Join the columns carrid, carrname and connid of the database tables scarr and spfli using an outer join. The column connid is set to the null value for all flights that do not fly from p_cityfr. This null value is then converted to the appropriate initial value when it is transferred to the assigned data object. The LOOP returns all airlines that do not fly from p_cityfr.
PARAMETERS p_cityfr TYPE spfli-cityfrom.
DATA: BEGIN OF wa,
carrid TYPE scarr-carrid,
carrname TYPE scarr-carrname,
connid TYPE spfli-connid,
END OF wa,
itab LIKE SORTED TABLE OF wa
WITH NON-UNIQUE KEY carrid.
SELECT scarrid scarrname p~connid
INTO CORRESPONDING FIELDS OF TABLE itab
FROM scarr AS s
LEFT OUTER JOIN spfli AS p ON scarrid = pcarrid
AND p~cityfrom = p_cityfr.
LOOP AT itab INTO wa.
IF wa-connid = '0000'.
WRITE: / wa-carrid, wa-carrname.
ENDIF.
ENDLOOP.
Cheers,
vasavi.
kindly reward if helpful.

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.

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

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.

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

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

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

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.

How to Resolve Join Syntax Errors in Crystal Reports 11.5

Weu2019re upgrading form Crystal Reports Runtime Client 10.0 to 11.5. I have a registry fix that resolves the join syntax errors in Crystal Reports 10.0 by updating the registry key:
[HKEY_LOCAL_MACHINE\Software\Crystal Decisions\10.0\Crystal Reports\Database\QueryBuilder\JoinBuilder]
"SQLServerJoinBuilder"="adbc"
What is the fix for Crystal Runtime 11.5?

Create a new key under:
HKEY_CURRENT_USER\Software\Business Objects\Suite 11.5\Crystal Reports\Database\QueryBuilder\JoinBuilder and add the values
"SQLServerJoinBuilder"="adbc"

When Mig Workbench will support the JOIN syntax?

Oracle 9i supports the ANSI SQL standard. The current workbench
version converts the JOIN syntax into the (+) syntax. Does
anybody know if and when the Migration Workbench will support
the JOIN syntax i.e. not try and convert it?
Thanks
Costas

Hi,
Oracle 9i now supported ANSI standard outer joins. We are
currently planning our coming releases of the Workbench and we
would hope to include outer join capability in version 2.0.3 of
the Workbench . We have not finalised plans yet but it looks like
being Q1 next Calendar year.
Regards
John

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

EJBQL join syntax example

Similar Messages

Maybe you are looking for