Why is a cross join classified as an inner join?

hi guys,
searching the web is just confusing me, so maybe someone here could help.
On wikipedia (for join) it says:
An outer join does not require each record in the two joined tables to have a matching record
Now, a cross join does not require any of the records of the table to have a matching record, therefore I would classify it as an outer join. Why then is it classified as an inner join?
thanks

Cross join produces the cross-product. You can not specify cross join condition since there is none - it always implies every row in table1 joined with every row in table2:
SQL> select ename,dname from emp cross join dept on(1=1)
2 /
select ename,dname from emp cross join dept on(1=1)
ERROR at line 1:
ORA-00933: SQL command not properly ended
SQL> With outer join you must specify join condition:
SQL> select ename,dname from emp left join dept
2 /
select ename,dname from emp left join dept
ERROR at line 1:
ORA-00905: missing keyword
SQL> And join result rules are completely different - matching rows or NULL row.
SY.

Similar Messages

Why is outer join more expensive than inner joins.

Why is outer join more expensive than inner joins.
Other than it may return more rows.
If you know of any ORA docs on this, please let me know.
Thanks.

Outer join is inner join with outer union applied on top of it. As you correctly observed it returns more rows and that alone makes it more expensive. Secondly, outer join is not commutative. As a result some join permutations are exclused from consideration, which results in higher cost.

Any differences between inner join and join without any keyword(inner join)

Are there any differences between following two join statements?
Join Statement 1:
select column1, column2 from table1 t1, table2 t2 where t1.t1Key=t2.t2Key;
Join Statement 2:
select column1, column2 from table1 t1 inner join table2 t2 on t1.t1Key = t2.t2Key;
Thanks for your reply.
Kevin

Hi, Kevin,
user13531850 wrote:
Are there any differences between following two join statements?To the system, those two are equivalent. They will produce exactly the same results, and will probably result in the same execution plan, so they will be equally efficient.
Some people find it easier to read and understand one rather than the other. Personally, I find the ANSI syntax (JOIN ... ON ...) easier to understand. The join conditions that apply to each table are listed right next to the table; you don't have to hunt through a long WHERE clause to find them. Also, it makes debugging easier. If you forget the join condition, then you get a syntax error, pinpointing where you forgot the join condition. Using the old syntax, if you forget a join condition, you get a cross-join, and it may not be obvious that any error occurred, but even if you do notice the mistake, you have no clue where it happened.
Join Statement 1:
select column1, column2 from table1 t1, table2 t2 where t1.t1Key=t2.t2Key;This is the old join syntax. It works in all versions of Oracle (so far).
Join Statement 2:
select column1, column2 from table1 t1 inner join table2 t2 on t1.t1Key = t2.t2Key;This is the ANSI join syntax. It works in Oracle 9.1 and higher. The keyword INNER is optional.

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

Performance considerations between a cross join and inner join

Hi there,
What's the performance difference and impact on running a cross-join based query against an inner join based query?
Regards and thanks

Before going to the performance issue - ensure you get the required data and not just some data shown.
Performance should be checked only between equivalent queries which produce same output but with different processing.
Are you sure you get same output in cross join as well as inner join?
If so pass on your different queries and then discuss with one is better.

The process time between INNER JOIN and join in WHERE clause

as u know, there are 2 kind of join
SELECT *
FROM tableA
INNER JOIN tableB
ON tableA.ID= tableB.ID
WHERE ....
and
SELECT *
FROM tableA, tableA
WHERE tableA.ID = tableB.ID
AND ....
I find the first one is faster in MS SQL Server.
But i test them in oracle and i find that it is the same. Is it correct?

Who knows why SQL Server shows different timings. Perhaps it's just cos it's not good at knowing that the two things are the same.
The only difference in timing as far as Oracle is concerned is the time it takes to parse the syntax of the query, which will be nanoseconds. The execution time of two equivalent queries will not differ based on the factor of the syntax used.

Inner join and select for all entries with respect to performance

Hi Friends,
I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient? and how? can you explain me in detail ?
Regards,
Dinesh

INNER JOIN->
The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ec77446011d189700000e8322d00/content.htm
FOR ALL ENTRIES->
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
Recommended
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.

Inner join command

Hi Forum,
How to use Inner join command?
Please explain with an example.
Thanks,
Mahathi

Inner Join and Outer Join
The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
The set of hits determined by an inner join can therefore be a subset of the hits determined with an outer join.
Database views implement an inner join. The database therefore only provides those records for which there is an entry in all the tables used in the view. Help views and maintenance views, however, implement an outer join.
Specifying Database Tables
The FROM clause determines the database tables from which the data specified in the SELECT clause is read. You can specify either a single table or more than one table, linked using inner or outer joins. The names of database tables may be specified statically or dynamically, and you can use alias names. You can also use the FROM clause to bypass the SAP buffer and restrict the number of lines to be read from the database.
"Database table" can equally mean an ABAP Dictionary view. A view links two or more database tables in the ABAP Dictionary, providing a static join that is available systemwide. You can specify the name of a view wherever the name of a database table may occur in the FROM clause.
The FROM clause has two parts - one for specifying database tables, and one for other additions:
SELECT... FROM <tables> <options>...
In <tables>, you specify the names of database tables and define joins. <options> allows you to specify further additions that control the database access.
Specifying Database Tables Statically
To specify the name of a database table statically, use the following:
SELECT... FROM <dbtab> [AS <alias>] <options> . ..
The database table <dbtab> must exist in the ABAP Dictionary. The AS addition allows you to specify an alternative name <alias> that you can then use in the SELECT; FROM, WHERE, and GROUP BY clauses. This can eliminate ambiguity when you use more than one database table, especially when you use a single database table more than once in a join. Once you have defined an alias, you may no longer use the real name of the database table
Specifying Database Tables Dynamically
To specify the name of a database table dynamically, use the following:
SELECT... FROM (<name>) <options> . ..
The field <name> must contain the name of a database table in the ABAP Dictionary. The table name must be written in uppercase. When you specify the name of a database table dynamically, you cannot use an empty INTO clause to read all of the columns into the work area <dbtab>. It is also not possible to use alternative table names.
Specifying Two or More Database Tables as an Inner Join
In a relational database, you normally need to read data simultaneously from more than one database table into an application program. You can read from more than one table in a single SELECT statement, such that the data in the tables all has to meet the same conditions, using the following join expression:
SELECT...
FROM <tab> [INNER] JOIN <dbtab> [AS <alias>] ON <cond> <options>
where <dbtab> is a single database table and <tab> is either a table or another join expression. The database tables can be specified statically or dynamically as described above. You may also use aliases. You can enclose each join expression in parentheses. The INNER addition is optional.
A join expression links each line of <tab> with the lines in <dbtab> that meet the condition <cond>. This means that there is always one or more lines from the right-hand table that is linked to each line from the left-hand table by the join. If <dbtab> does not contain any lines that meet the condition <cond>, the line from <tab> is not included in the selection.
The syntax of the <cond> condition is like that of the WHERE clause, although individual comparisons can only be linked using AND. Furthermore, each comparison must contain a column from the right-hand table <dbtab>. It does not matter on which side of the comparison it occurs. For the column names in the comparison, you can use the same names that occur in the SELECT clause, to differentiate columns from different database tables that have the same names.
The comparisons in the condition <cond> can appear in the WHERE clause instead of the ON clause, since both clauses are applied equally to the temporary table containing all of the lines resulting from the join. However, each join must contain at least one comparison in the condition <cond>.
Specifying Two or More Database Tables as a Left Outer Join
In an inner join, a line from the left-hand database table or join is only included in the selection if there is one or more lines in the right-hand database table that meet the ON condition <cond>. The left outer join, on the other hand, reads lines from the left-hand database table or join even if there is no corresponding line in the right-hand table.
SELECT...
FROM <tab> LEFT [OUTER] JOIN <dbtab> [AS <alias>] ON <cond>
       <options>
<tab> and <dbtab> are subject to the same rules and conditions as in an inner join. The OUTER addition is optional. The tables are linked in the same way as the inner join with the one exception that all lines selected from <tab> are included in the final selection. If <dbtab> does not contain any lines that meet the condition <cond>, the system includes a single line in the selection whose columns from <dbtab> are filled with null values.
In the left outer join, more restrictions apply to the condition <cond> than in the inner join. In addition to the above restrictions:
EQ or = is the only permitted relational operator.
There must be at least one comparison between columns from <tab> and <dbtab>.
The WHERE clause may not contain any comparisons with columns from <dbtab>. All comparisons using columns from <dbtab> must appear in the condition <cond>.
Client Handling
As already mentioned, you can switch off the automatic client handling in Open SQL statements using a special addition. In the SELECT statement, the addition comes after the options in the FROM clause:
SELECT... FROM <tables> CLIENT SPECIFIED. ..
If you use this addition, you can then address the client fields in the individual clauses of the SELECT statement.
Disabling Data Buffering
If buffering is allowed for a table in the ABAP Dictionary, the SELECT statement always reads the data from the buffer in the database interface of the current application server. To read data directly from the database table instead of from the buffer, use the following:
SELECT... FROM <tables> BYPASSING BUFFER. ..
This addition guarantees that the data you read is the most up to date. However, as a rule, only data that does not change frequently should be buffered, and using the buffer where appropriate improves performance. You should therefore only use this option where really necessary.
Restricting the Number of Lines
To restrict the absolute number of lines included in the selection, use the following:
SELECT... FROM <tables> UP TO <n> ROWS. ..
If <n> is a positive integer, the system reads a maximum of <n> lines. If <n> is zero, the system reads all lines that meet the selection criteria. If you use the ORDER BY clause as well, the system reads all lines belonging to the selection, sorts them, and then places the first <n> lines in the selection set.
Examples
Specifying a database table statically:
REPORT demo_select_static_database.
DATA wa TYPE scarr.
SELECT *
INTO wa
FROM scarr UP TO 4 ROWS.
WRITE: / wa-carrid, wa-carrname.
ENDSELECT.
The output is:
The system reads four lines from the database table SCARR.
Specifying a database table dynamically:
REPORT demo_select_dynamic_database.
DATA wa TYPE scarr.
DATA name(10) TYPE c VALUE 'SCARR'.
SELECT *
INTO wa
FROM (name) CLIENT SPECIFIED
WHERE mandt = '000'.
WRITE: / wa-carrid, wa-carrname.
ENDSELECT.
A condition for the MANDT field is allowed, since the example uses the CLIENT SPECIFIED option. If NAME had contained the value scarr instead of SCARR, a runtime error would have occurred.
Inner join:
REPORT demo_select_inner_join.
DATA: BEGIN OF wa,
        carrid TYPE spfli-carrid,
        connid TYPE spfli-connid,
        fldate TYPE sflight-fldate,
        bookid TYPE sbook-bookid,
      END OF wa,
      itab LIKE SORTED TABLE OF wa
                WITH UNIQUE KEY carrid connid fldate bookid.
SELECT pcarrid pconnid ffldate bbookid
INTO CORRESPONDING FIELDS OF TABLE itab
FROM ( ( spfli AS p
            INNER JOIN sflight AS f ON pcarrid = fcarrid AND
                                       pconnid = fconnid    )
            INNER JOIN sbook   AS b ON bcarrid = fcarrid AND
                                       bconnid = fconnid AND
                                       bfldate = ffldate     )
WHERE p~cityfrom = 'FRANKFURT' AND
        p~cityto   = 'NEW YORK' AND
        fseatsmax > fseatsocc.
LOOP AT itab INTO wa.
AT NEW fldate.
    WRITE: / wa-carrid, wa-connid, wa-fldate.
ENDAT.
WRITE / wa-bookid.
ENDLOOP.
This example links the columns CARRID, CONNID, FLDATE, and BOOKID of the table SPFLI, SFLIGHT, and SBOOK, and creates a list of booking numbers for all flights from Frankfurt to New York that are not fully booked. An alias name is assigned to each table.
Left outer join:
REPORT demo_select_left_outer_join.
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 = 'FRANKFURT'.
LOOP AT itab INTO wa.
WRITE: / wa-carrid, wa-carrname, wa-connid.
ENDLOOP.
The output might look like this:
The example links the columns CARRID, CARRNAME, and CONNID of the tables SCARR and SPFLI using the condition in the left outer join that the airline must fly from Frankfurt. All other airlines have a null value in the CONNID column in the selection.
If the left outer join is replaced with an inner join, the list looks like this:
Only lines that fulfill the ON condition are included in the selection.

Performance difference between left outer join / inner join

Hi,
I've got a complex query which among other things accesses quite a large table. If I use inner join to join this table, the response is quite fast and execution plan shows it uses nested loops to gather the data.
If I change inner join to left outer join, I get a big performance drop. Cost of query goes from 1441 to 28544.
I don't uderstand why there's such a difference. For inner join, database has to remove all the rows that don't have match in inner-joined table. For left join it can keep all records and just return NULL values for records that don't have a match. In my mind left join should be faster, as it seems simpler. And the access plan could be the same, couldn't it?
Execution plan for inner join:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 288 | 1441 (1)| 00:00:18 |
| 1 | HASH GROUP BY | | 1 | 288 | 1441 (1)| 00:00:18 |
| 2 | NESTED LOOPS OUTER | | 1 | 288 | 1440 (1)| 00:00:18 |
| 3 | NESTED LOOPS | | 1 | 261 | 1438 (1)| 00:00:18 |
| 4 | NESTED LOOPS | | 318 | 74412 | 508 (1)| 00:00:07 |
| 5 | NESTED LOOPS | | 318 | 51834 | 189 (0)| 00:00:03 |
| 6 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | 1 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | 0 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | 188 (0)| 00:00:03 |
|* 9 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | 3 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | TASK_PK | 1 | | 0 (0)| 00:00:01 |
| 12 | TABLE ACCESS BY INDEX ROWID | TASK_WORK_HISTORY | 1 | 27 | 3 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TASK_WORK_HISTORY_INDEX1 | 1 | | 2 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | TASK_USES_RESURCE | 1 | 27 | 2 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | TASK_USES_RESURCE_UK1 | 1 | | 1 (0)| 00:00:01 |
For left outer join:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 318 | 1596K| | 28544 (2)| 00:05:43 |
|* 1 | HASH JOIN OUTER | | 318 | 1596K| 1584K| 28544 (2)| 00:05:43 |
| 2 | VIEW | | 318 | 1580K| | 508 (1)| 00:00:07 |
| 3 | NESTED LOOPS | | 318 | 74412 | | 508 (1)| 00:00:07 |
| 4 | NESTED LOOPS | | 318 | 51834 | | 189 (0)| 00:00:03 |
| 5 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | | 1 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | | 0 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | | 188 (0)| 00:00:03 |
|* 8 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | | 3 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | TASK_PK | 1 | | | 0 (0)| 00:00:01 |
| 11 | VIEW | | 1480K| 73M| | 23431 (2)| 00:04:42 |
|* 12 | HASH JOIN RIGHT OUTER | | 1480K| 76M| 38M| 23431 (2)| 00:04:42 |
| 13 | TABLE ACCESS FULL | TASK_USES_RESURCE | 1486K| 21M| | 2938 (2)| 00:00:36 |
| 14 | VIEW | | 1445K| 53M| | 15031 (2)| 00:03:01 |
| 15 | HASH GROUP BY | | 1445K| 37M| 110M| 15031 (2)| 00:03:01 |
| 16 | TABLE ACCESS FULL | TASK_WORK_HISTORY | 1445K| 37M| | 3897 (2)| 00:00:47 |
--------------------------------------------------------------------------------------------------------------------------

...continued
Complete execution plan for left join:
| Id | Operation                       | Name                           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |                                |   318 | 1594K|       | 28544   (2)| 00:05:43 |
|* 1 | HASH JOIN OUTER                |                                |   318 | 1594K| 1584K| 28544   (2)| 00:05:43 |
|   2 |   VIEW                          |                                |   318 | 1578K|       |   508   (1)| 00:00:07 |
|   3 |    NESTED LOOPS                 |                                |   318 | 74412 |       |   508   (1)| 00:00:07 |
|   4 |     NESTED LOOPS                |                                |   318 | 51834 |       |   189   (0)| 00:00:03 |
|   5 |      TABLE ACCESS BY INDEX ROWID| RESURCE                        |     1 |   106 |       |     1   (0)| 00:00:01 |
|* 6 |       INDEX UNIQUE SCAN         | RESURCE_PRINCIPAL_NAME_INDEX   |     1 |       |       |     0   (0)| 00:00:01 |
|   7 |      TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE              |   318 | 18126 |       |   188   (0)| 00:00:03 |
|* 8 |       INDEX RANGE SCAN          | TASK_USES_RESUR_IDX$$_0CDC0002 |   318 |       |       |     3   (0)| 00:00:01 |
|   9 |     TABLE ACCESS BY INDEX ROWID | TASK                           |     1 |    71 |       |     1   (0)| 00:00:01 |
|* 10 |      INDEX UNIQUE SCAN          | TASK_PK                        |     1 |       |       |     0   (0)| 00:00:01 |
| 11 |   VIEW                          |                                | 1480K|    73M|       | 23431   (2)| 00:04:42 |
|* 12 |    HASH JOIN RIGHT OUTER        |                                | 1480K|    76M|    38M| 23431   (2)| 00:04:42 |
| 13 |     TABLE ACCESS FULL           | TASK_USES_RESURCE              | 1486K|    21M|       | 2938   (2)| 00:00:36 |
| 14 |     VIEW                        |                                | 1445K|    53M|       | 15031   (2)| 00:03:01 |
| 15 |      HASH GROUP BY              |                                | 1445K|    37M|   110M| 15031   (2)| 00:03:01 |
| 16 |       TABLE ACCESS FULL         | TASK_WORK_HISTORY              | 1445K|    37M|       | 3897   (2)| 00:00:47 |
Query Block Name / Object Alias (identified by operation id):
   1 - SEL$1AFB0324
   2 - SEL$58A6D7F6 / from$_subquery$_005@SEL$8
   3 - SEL$58A6D7F6
   5 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2
   6 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2
   7 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1
   8 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1
   9 - SEL$58A6D7F6 / TASK@SEL$1
10 - SEL$58A6D7F6 / TASK@SEL$1
11 - SEL$7EBCC247 / TRW@SEL$3
12 - SEL$7EBCC247
13 - SEL$7EBCC247 / TUR@SEL$4
14 - SEL$6        / TRW_IN@SEL$5
15 - SEL$6
16 - SEL$6        / TWH@SEL$6
Predicate Information (identified by operation id):
   1 - access("TRW"."RESURCE_ID"(+)="TASKUSESRESURCE"."RESURCE_ID" AND "TRW"."TASK_ID"(+)="TASK"."ID")
   6 - access("RESURCEWORKER"."USER_PRINCIPAL_NAME"=U'jernej')
   8 - access("TASKUSESRESURCE"."RESURCE_ID"="RESURCEWORKER"."ID")
10 - access("TASKUSESRESURCE"."TASK_ID"="TASK"."ID")
12 - access("TUR"."RESURCE_ID"(+)="TRW_IN"."RESURCE_ID" AND "TUR"."TASK_ID"(+)="TRW_IN"."TASK_ID")                                                                                                                                                                                                         Jonathan, I've been to one of your workshops in Ljubljana. I'm still trying to understand everything you explained and use it, but there's much I have to learn and understand.
The way I see this query it should fist join and filter the first three tables and only then join the trw subquery. The problem with this subqrey is task_work_history table, which is accessed in very different ways in different places, so there will always be many reads to gather required data. For now, however, I'd be hapy to just bring the performance of inner join to left join...

Join two table (Inner Join)

how to join two tables using inner join.

Tariq,
Pretty vague question. You can create joins in an ABAP program, or while creating a view, or when creating a SAP query of one type or another. Some people download tables and then join them using desktop software. If you can elaborate your question I may be able to give you a better answer.
I recently joined two wooden tables at a picnic. I used 24 gauge galvanized wire combined with duct tape, so I guess you couldn't really call that an 'inner join'.
Best Regards,
DB49

Bind variables in inner join queries

Hi all,
can we use bind variables in inner join queries?
eg:
INNER JOIN PRTY_LOC_CODE_T plc ON (ppt.PRTY_REC_ID = plc.PRTY_REC_ID and plc.HIST_CTRL_IND = *0*_ and plc.DEL_IND = *'N'*_)
regards
sunil

Dear,
can we use bind variables in inner join queries?Where are you using this join? if in a stored procedure or stored function than you don't have to care about your variables. It will be automatically considered as a bind variable
within your static SQL (i.e in your stored procedure)
Hope this helps
Mohamed Houri

Inner join in webi

Hi,
currently i am generating a report basing on the two databases netezaa,DB2
There are 4 sql queries basing on two databases.By looking into query i am selecting fileds.
Each query consists of inner join.So how can i generate an inner join in report?what is the best practice i mean in infoview i have no access to customize sql.
Thanks in Advance
Regards,
Sunil

Hi,
If i do that then Sql query forms an inner join,Becoz i have already created two queries and merged basing on dimension untill here it is fine.But where as coming to the next one i.e 3rd one
select ______from ____
inner join ______on ____=____
inner join ______on ____=____
inner join ______on ____=____
where _______;
It is of this format now what i need to do becoz after select statement it is directly going into inner join;;;I have face this similar one with 2nd query there is query in a query with inner join that time i have created a Filter for that subquery and passed in the report .Can you plz suggest me
Thanks

Inner join Vs for all entries for performance

hi,
i need to fetch data from 5 tables where i have common key vbeln, is this suggestable to write a select query with inner join or write an inner join for 2 tables with more fileds and for remaining using for all entries.... please suggest how can i increase the performance...all points are rewarded....
thnaks alot.

Is this a dialog program or a data extract? Rob is right in that the difference is negligible IF the number of records involved are only a few.
On the other hand, if you are extracting a large number of records, then the performance depends on a number of things and is generally unpredictable.
The way I approach it is by first developing the extract program with a join because it is easier to code. If the program run time is within the acceptable range, I would let it be and migrate to production. If the performance is of high priority and if the join appears to take long time, then I will comment out the code and try the FAE approach. If the run time with FAE is not markedly better, then I would go back to join.

Why would Shape Builder not allow Selecting (for a join)?

(As background . . . I ran through Terry White's excellent "10 things" for Illustrator video. I even built the Yin-Yang symbol myself, from scratch, after watching his video. So "I have" succeeded at least once in using Shape Builder.)
But, when I attempt to do . . . pretty much anything of my own design . . . I get stuck within the first minute and just have to quit and walk away. I appologize in advance if anything sounds bad . . . I'm FULLY MAXED OUT on both anger and frustration. Its just inconsolably frustrating how easy it is to get into a "mode" that . . . won't let you go any further.
Imagine drawing a cross. (Like if you took real 4" x 4"'s and made a physical one, and then traced the outline around that.)
I thought I'd draw one long vertical rectangle.
Then draw an overlapping shorter horizontal rectangle.
Then join the two together in Shape Builder so its one "bounded box" with no interior "crossing lines" in the central join.
I drew the two rectangles. Even got them centered vertically using the align button.
I select the Shape Builder and . . . . am immediately hopelessly stuck in one of two modes that won't let me continue further.
#1 (From a fresh "web" document) . . . I hover over the vertical beam (cross hatch appears, and the "+" appears because I'm in Shape Builder Add mode) and . . . cross hatch won't appear as I drag over the horizontal crossbeam.
Or . . . click (and hold) on the crossbeam . . . same thing . . . cross hatch appears, the "+" is there and . . . as I drag to the vertical beam to join . . . it won't go to crosshatch.
Or . . .
#2 (When I was originally trying to add this as part of a larger board) . . . I drew the same two rectangles, then upon choosing Shape Builder . . . I get an Arrow and a Circle with a Slash through it and am not allowed to select anything.
And can't find any sign, in any panel, of any "mode" I'm in (or not in) that would account for why selection is blocked.
I wasn't on the wrong layer (there is only one).
I've tried it (#1) from a new fresh drawing, and (#2) from inside a larger drawing (where I actually need it).
It takes less than 30 seconds from start to . . . . hopelessly blocked from proceeding.
Why wouldn't Shape Builder allow two pieces to join?
Why would Shape Builder show "not allowed to select"?
Thanks,
jkh

See, I'm in Shape Builder . . . Cross Hatch appears.
(Its probably too small on the image, but trust me . . . there is a "+" by the arrow.)
It was so simple on the Yin-Yang Cirle to Teardrop join . . . this is an EVEN SIMPLER image and . . . I'm stuck at step 1.

Why can't i use "INNER JOIN" in a query for SQL Server with JDBC??????

Hi,
I'm trying to execute some SQL queries and I just don't understand what's wrong.
I�m using Tomcat and SQL Server in order to do this, but when I�m try to execute a query with a INNER JOIN statements Tomcat raise a SQL exception... at the very first time I thought there was a problem with database connection but I realize that a simple query to a table works pretty well. then I found out some problems with JDBC:ODBC.... so I install JDBC for SQL Server 2000 and test with the same simple query and works..... so, I come to a conclusion.... INNER JOIN or JOIN statements can't be used in JDBC..... please... somebody tell I�m wrong and give me a hand...
I'm using TOMCAT 4 and JDK 1.4 SQL Server 2000
Error occurs when executeQuery() is called.... not prepareStatement().... ??????
Driver DriverRecResult = (Driver)Class.forName(driver).newInstance();
Connection ConnRecResult = DriverManager.getConnection(DSN,user,password);
PreparedStatement StatementRecResult = ConnRecResult.prepareStatement(query);
ResultSet RecResult = StatementRecResult.executeQuery(); <---- Exception raise here
So much tahnks in advance,

That's exactly what I think, driver it's raising the exception, but I don't know why.... i test the same query with INNER JOIN directly from SQL Query Analyser and it's works perfectly, my problem ain't SQL, but JSP and JDBC 'cause i'm a newbie about these issues.
Common sense tell me possible problems lie in SQLServer drivers 'cause i run the same pages on JRUN through jdbc:odbc and do works well, but by now i just depend on Tomcat.....
I've installed SQL Server drivers for JDBC but i just find it doesn't work fully... could be the version of JDK i've installed? what version do i need?
( I'm running Tomcat 4 with JDK 1.4 & SQL Server 2000 W2K )
thanks for reply.

Why is a cross join classified as an inner join?

Similar Messages

Maybe you are looking for