Comments on: Oracle RDBMS 11gR2 – goodbye Connect By or: the end of hierarchical querying as we know it https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/ Friends of Oracle and Java Wed, 27 May 2015 22:00:57 +0000 hourly 1 http://wordpress.org/?v=4.2.2 By: Abhilesh https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5904 Tue, 14 Feb 2012 06:13:36 +0000 http://technology.amis.nl/blog/?p=6104#comment-5904 Just for community update. Issue raised by me in comment #19 has been accepted by Oracle as a defect.
Oracle has provided a patch for the same for Linux environment.
Below are the defect details:
Defect Id: 3-5078219271
Those who need it can access the patch via https://support.oracle.com/

]]>
By: Abhilesh https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5903 Tue, 13 Dec 2011 13:23:51 +0000 http://technology.amis.nl/blog/?p=6104#comment-5903 Hi Lucas
Some more info. In this query, CONNECT BY PRIOR is used at two places. It’s the second occurrence that is reporting an error. Only difference between the two is that later is part of an INNERT JOIN condition. Is this valid?
Abhilesh

]]>
By: HariVishnu https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5902 Tue, 13 Dec 2011 12:00:24 +0000 http://technology.amis.nl/blog/?p=6104#comment-5902 Hi Lucas/Abhliesh,
With a small investigation what I found out is there is not problem with the ‘connect by prior’ in the second argument of ‘Inner Join’, but the problem mainly is with the ‘connect by prior’ in the inner join condition. It seems like with the latest oracle version ‘LEVEL, PRIOR, ROWNUM’ are not allowed in join conndition

]]>
By: Abhilesh https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5901 Tue, 13 Dec 2011 08:29:31 +0000 http://technology.amis.nl/blog/?p=6104#comment-5901  
Hi Lucas,
Indeed you are right. Query mentioned above does work. However, following query which was working earlier on Oracle 11.2.0.1 doesn’t work on 11.2.0.3. My apologies for generalizing it with my assumption.
My table structure is as shown below.
CREATE TABLE APP_BRANCH
(
BRANCH_ID varchar2 (50) NOT NULL ,
PARENT_ID varchar2 (50) DEFAULT ‘ ‘,
REGISTERED_REVISION varchar2 (50) NOT NULL ,
NAME nvarchar2 (500) NOT NULL ,
STACK_LEVEL number (4, 0) NOT NULL,
CONSTRAINT PK_SPACE PRIMARY KEY (BRANCH_ID)
);
CREATE TABLE APP_DOC
(
REVISION varchar2 (50) NOT NULL ,
DOCUMENT_ID varchar2 (50) NOT NULL ,
NAME nvarchar2 (255) NOT NULL ,
TYPE_ID varchar2 (50) NOT NULL ,
TYPE_REVISION varchar2 (50) NOT NULL ,
PARENT_ID varchar2 (50) DEFAULT ‘ ‘,
CONTENT CLOB   NULL ,
STACK_LEVEL number (4, 0) NOT NULL,
CONSTRAINT PK_DOC PRIMARY KEY (REVISION, DOCUMENT_ID)
);
Here goes the query that fails.
SELECT /*+ FIRST_ROWS(10) PARALLEL (APP_DOC, 4) INDEX(APP_DOC PK_DOC) */ APP_DOC.REVISION, APP_DOC.DOCUMENT_ID, APP_DOC.NAME, APP_DOC.STACK_LEVEL , APP_DOC.CONTENT FROM APP_DOC INNER JOIN (SELECT D2.DOCUMENT_ID , MAX(STACK_LEVEL) AS BLEVEL FROM APP_DOC D2 WHERE D2.REVISION IN (SELECT REGISTERED_REVISION FROM APP_BRANCH START WITH BRANCH_ID = :REVISION CONNECT BY PRIOR PARENT_ID = BRANCH_ID) AND D2.DOCUMENT_ID = :DOCUMENT_ID AND D2.TYPE_ID = :TYPE_ID GROUP BY D2.DOCUMENT_ID) SUB_RESULT ON APP_DOC.REVISION IN(SELECT REGISTERED_REVISION FROM APP_BRANCH START WITH BRANCH_ID = :REVISION CONNECT BY PRIOR PARENT_ID = BRANCH_ID) AND APP_DOC.STACK_LEVEL = SUB_RESULT.BLEVEL AND APP_DOC.DOCUMENT_ID=SUB_RESULT.DOCUMENT_ID
Reports the same error. Error conveys following
Cause: LEVEL, PRIOR, or ROWNUM is being specified at illegal location.
Action: Remove LEVEL, PRIOR, or ROWNUM.
In above query, only suspect is PRIOR keyword. Concern here is that the same query was working fine with previous Oracle releases but failed for Oracle 11.2.0.3. Why?
Abhilesh
 

]]>
By: Lucas Jellema https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5900 Sun, 11 Dec 2011 08:35:29 +0000 http://technology.amis.nl/blog/?p=6104#comment-5900 Hi Abhilesh,

 

I do not think Oracle will ever desupport CONNECT BY PRIOR, do not fear.

 

Could you describe the exact table APP_BRANCH that you are running this query against? I can see no apparent reason why your query should not work.

The Recursive Sub Query Equivalent would be something like:

with branches(id, parent_id, branch_label) as
( select branch_id id
,      parent_id parent_id
,      branch_name branch_label
from   app_branch
union all
select a.branch_id id
,      a.parent_id parent_id
,      a.branch_name branch_label
from   app_branch a
join
branches b
on (a.parent_id = b.id)
)
select *
from   branches

(assuming a table definition such as:

create table app_branch
( parent_id number(5)
, branch_id number(5) not null primary key
, branch_name varchar2(100)
)

)

 

Lucas

]]>
By: Abhilesh https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5899 Fri, 09 Dec 2011 13:55:47 +0000 http://technology.amis.nl/blog/?p=6104#comment-5899 Hi Lucas,
Does it mean that CONNECT BY PRIOR will not be supported by next versions of Oracle11g?
I put this question because I’ve already got following error after upgrading Oracle server from 11.2.0.1 to 11.2.0.3. Till now I could not find any official documentation from Oracle that conveys the same.
Query is:

SELECT BRANCH_NAME FROM APP_BRANCH START WITH BRANCH_ID = ? CONNECT BY PRIOR PARENT_ID = BRANCH_ID

Error: ORA-00976: Specified pseudocolumn or operator not allowed here
Any pointers or help appreciated. Also, what could be an alternative ANSI query?

Abhilesh

]]>
By: Lucas Jellema https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5898 Sun, 13 Nov 2011 13:47:52 +0000 http://technology.amis.nl/blog/?p=6104#comment-5898 Thanks Michiel for you suggestion for the alternative to CONNECT_BY_ROOT.

Lucas

]]>
By: Lucas Jellema https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5897 Sun, 13 Nov 2011 13:46:37 +0000 http://technology.amis.nl/blog/?p=6104#comment-5897 Hi Cecil New,

If you take a look at my response to Adamp, that may already give you your answer. Nodes will not be revisited. However, that may mean you will not have the data you need. Could you please send me DDL scripts for your table structure and the query you would be using with CONNECT BY if that would work? Then I can take a closer look at what you are exactly asking for.

Lucas

]]>
By: Lucas Jellema https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5896 Sun, 13 Nov 2011 13:44:54 +0000 http://technology.amis.nl/blog/?p=6104#comment-5896 Hi Adamp,

It does have a similar protection against endless loops – through the construction:

 

CYCLE name SET is_cycle TO ‘Y’ DEFAULT ‘N’

When a node is encountered for the second time, it will be included  in the result set, its column value IS_CYCLE (a new column I am introducing with the statement above) is set to Y and the recursion stops then and there – so there will not be a second iteration starting at this node. Note however that any node where a cycle starts is included in the result set twice.

 

Lucas

]]>
By: Cecil New https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5895 Thu, 03 Nov 2011 11:12:51 +0000 http://technology.amis.nl/blog/?p=6104#comment-5895 A common problem with product structures (or bills-of-material) in product management tools, is a query that will return all parts, past and present.
By past, I mean “revisions” of the assembly structure.  Each assembly node at each level may have many revisions.  As a practical matter, the most of the data is repeated revision to revision.  This means that CONNECT BY wastes a lot of time revisiting nodes in the tree – actually, most cases it never finishes.  So to handle this problem I have resorted to doing the recursion in logic, keeping track of visited nodes and skipping them if encountered again.
Are there any feature in 11g that implement a “don’t revisit node” approach?  Or can the new WITH syntax implement this approach?

]]>
By: Alessandro Maioli https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5894 Fri, 09 Sep 2011 13:15:15 +0000 http://technology.amis.nl/blog/?p=6104#comment-5894 I was wondering about perfomance of  hierarchical query using  “WITH” and aliasing column vs the same query made using the “CONNECT BY” with high volume of data:
It will be fast as the use of  “CONNECT BY” on Oracle DB of previous version (11gR1 and below) with the constetual use of :
ALTER SESSION SET “_OLD_CONNECT_BY_ENABLED” = TRUE;
I found only measure of WITH clause vs “CONNECT BY” on Oracle 11gR2, but on that version the “CONNECT BY” performance become poor since _OLD_CONNECT_BY_ENABLED cannot be used…

]]>
By: Michiel Vermandel https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5893 Thu, 25 Aug 2011 13:52:45 +0000 http://technology.amis.nl/blog/?p=6104#comment-5893 If you want the Oracle CONNECT_BY_ROOT functionality as well, you can use this query (root column):
with employees (empno, name, mgr, hierlevel, path, root) as
( select empno, ename, job, mgr, 1, ename, ename
from   emp
where  mgr is null
union all
select e.empno, e.ename, e.job
,      e.mgr, m.hierlevel + 1
,      m.path||’/’||e.ename,  m.root
from   emp e
join
employees m
on (m.empno = e.mgr)
)
select * from   employees

]]>
By: adamp https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5892 Mon, 03 Jan 2011 22:15:41 +0000 http://technology.amis.nl/blog/?p=6104#comment-5892 Is there any way to protect against loops like the NOCYCLE clause does for the CONNECT BY syntax, or does this already protect against loops somehow?

]]>
By: jock https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5891 Fri, 12 Mar 2010 07:16:23 +0000 http://technology.amis.nl/blog/?p=6104#comment-5891 “I assume it is equally fast – though it may be a little bit faster (I have not tried it out)” – can you try it out ? Normally you would have an index on MGR, connect by would have used it to good effect. Also, try with walking up and down the tree and not just starting at root level.

]]>
By: Manu Kaul https://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5890 Thu, 21 Jan 2010 16:39:08 +0000 http://technology.amis.nl/blog/?p=6104#comment-5890 Very good article! I was wondering if I could run past you a problem that requires a recursive SQL such as this. Would this be ok?

]]>