<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Oracle RDBMS 11gR2 &#8211; goodbye Connect By or: the end of hierarchical querying as we know it</title>
	<atom:link href="http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/feed/" rel="self" type="application/rss+xml" />
	<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it</link>
	<description></description>
	<lastBuildDate>Fri, 12 Apr 2013 10:04:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Abhilesh</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5904</link>
		<dc:creator>Abhilesh</dc:creator>
		<pubDate>Tue, 14 Feb 2012 06:13:36 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5904</guid>
		<description><![CDATA[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:
&lt;strong&gt;Defect Id:&lt;/strong&gt; 3-5078219271
Those who need it can access the patch via https://support.oracle.com/]]></description>
		<content:encoded><![CDATA[<p>Just for community update. Issue raised by me in comment #19 has been accepted by Oracle as a defect.<br />
Oracle has provided a patch for the same for Linux environment.<br />
Below are the defect details:<br />
<strong>Defect Id:</strong> 3-5078219271<br />
Those who need it can access the patch via <a href="https://support.oracle.com/" rel="nofollow">https://support.oracle.com/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abhilesh</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5903</link>
		<dc:creator>Abhilesh</dc:creator>
		<pubDate>Tue, 13 Dec 2011 13:23:51 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5903</guid>
		<description><![CDATA[Hi Lucas
Some more info. In this query, CONNECT BY PRIOR is used at two places. It&#039;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]]></description>
		<content:encoded><![CDATA[<p>Hi Lucas<br />
Some more info. In this query, CONNECT BY PRIOR is used at two places. It&#8217;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?<br />
Abhilesh</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: HariVishnu</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5902</link>
		<dc:creator>HariVishnu</dc:creator>
		<pubDate>Tue, 13 Dec 2011 12:00:24 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5902</guid>
		<description><![CDATA[Hi Lucas/Abhliesh,
With a small investigation what I found out is there is not problem with the &#039;connect by prior&#039; in the second argument of &#039;Inner Join&#039;, but the problem mainly is with the &#039;connect by prior&#039; in the inner join condition. It seems like with the latest oracle version &#039;LEVEL, PRIOR, ROWNUM&#039; are not allowed in join conndition]]></description>
		<content:encoded><![CDATA[<p>Hi Lucas/Abhliesh,<br />
With a small investigation what I found out is there is not problem with the &#8216;connect by prior&#8217; in the second argument of &#8216;Inner Join&#8217;, but the problem mainly is with the &#8216;connect by prior&#8217; in the inner join condition. It seems like with the latest oracle version &#8216;LEVEL, PRIOR, ROWNUM&#8217; are not allowed in join conndition</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abhilesh</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5901</link>
		<dc:creator>Abhilesh</dc:creator>
		<pubDate>Tue, 13 Dec 2011 08:29:31 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5901</guid>
		<description><![CDATA[Â 
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&#039;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 &#039; &#039;,
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 &#039; &#039;,
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
Â ]]></description>
		<content:encoded><![CDATA[<p>Â <br />
Hi Lucas,<br />
Indeed you are right. Query mentioned above does work. However, following query which was working earlier on Oracle 11.2.0.1 doesn&#8217;t work on 11.2.0.3. My apologies for generalizing it with my assumption.<br />
My table structure is as shown below.<br />
CREATE TABLE APP_BRANCH<br />
(<br />
BRANCH_ID varchar2 (50) NOT NULL ,<br />
PARENT_ID varchar2 (50) DEFAULT &#8216; &#8216;,<br />
REGISTERED_REVISION varchar2 (50) NOT NULL ,<br />
NAME nvarchar2 (500) NOT NULL ,<br />
STACK_LEVEL number (4, 0) NOT NULL,<br />
CONSTRAINT PK_SPACE PRIMARY KEY (BRANCH_ID)<br />
);<br />
CREATE TABLE APP_DOC<br />
(<br />
REVISION varchar2 (50) NOT NULL ,<br />
DOCUMENT_ID varchar2 (50) NOT NULL ,<br />
NAME nvarchar2 (255) NOT NULL ,<br />
TYPE_ID varchar2 (50) NOT NULL ,<br />
TYPE_REVISION varchar2 (50) NOT NULL ,<br />
PARENT_ID varchar2 (50) DEFAULT &#8216; &#8216;,<br />
CONTENT CLOB Â  NULL ,<br />
STACK_LEVEL number (4, 0) NOT NULL,<br />
CONSTRAINT PK_DOC PRIMARY KEY (REVISION, DOCUMENT_ID)<br />
);<br />
Here goes the query that fails.<br />
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 = <img src='http://technology.amis.nl/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> OCUMENT_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<br />
Reports the same error. Error conveys following<br />
Cause:  LEVEL, PRIOR, or ROWNUM is being specified at illegal location.<br />
Action:  Remove LEVEL, PRIOR, or ROWNUM.<br />
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?<br />
Abhilesh<br />
Â </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Jellema</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5900</link>
		<dc:creator>Lucas Jellema</dc:creator>
		<pubDate>Sun, 11 Dec 2011 08:35:29 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5900</guid>
		<description><![CDATA[&lt;p&gt;Hi Abhilesh,&lt;/p&gt;
&lt;p&gt;Â &lt;/p&gt;
&lt;p&gt;I do not think Oracle will ever desupport CONNECT BY PRIOR, do not fear.&lt;/p&gt;
&lt;p&gt;Â &lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The Recursive Sub Query Equivalent would be something like:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;(assuming a table definition such as:&lt;/p&gt;
&lt;p&gt;create table app_branch
( parent_id number(5)
, branch_id number(5) not null primary key
, branch_name varchar2(100)
)&lt;/p&gt;
&lt;p&gt;)&lt;/p&gt;
&lt;p&gt;Â &lt;/p&gt;
&lt;p&gt;Lucas&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Hi Abhilesh,</p>
<p>Â </p>
<p>I do not think Oracle will ever desupport CONNECT BY PRIOR, do not fear.</p>
<p>Â </p>
<p>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.</p>
<p>The Recursive Sub Query Equivalent would be something like:</p>
<p>with branches(id, parent_id, branch_label) as<br />
( select branch_id id<br />
 ,Â Â Â Â Â  parent_id parent_id<br />
 ,Â Â Â Â Â  branch_name branch_label<br />
 fromÂ Â  app_branch<br />
 union all<br />
 select a.branch_id id<br />
 ,Â Â Â Â Â  a.parent_id parent_id<br />
 ,Â Â Â Â Â  a.branch_name branch_label<br />
 fromÂ Â  app_branch a<br />
 join<br />
 branches b<br />
 on (a.parent_id = b.id)<br />
)<br />
select *<br />
fromÂ Â  branches</p>
<p>(assuming a table definition such as:</p>
<p>create table app_branch<br />
( parent_id number(5)<br />
, branch_id number(5) not null primary key<br />
, branch_name varchar2(100)<br />
)</p>
<p>)</p>
<p>Â </p>
<p>Lucas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abhilesh</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5899</link>
		<dc:creator>Abhilesh</dc:creator>
		<pubDate>Fri, 09 Dec 2011 13:55:47 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5899</guid>
		<description><![CDATA[Hi Lucas,
Does it mean that CONNECT BY PRIOR will not be supported by next versions of Oracle11g?
I put this question because I&#039;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]]></description>
		<content:encoded><![CDATA[<p>Hi Lucas,<br />
Does it mean that CONNECT BY PRIOR will not be supported by next versions of Oracle11g?<br />
I put this question because I&#8217;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.<br />
Query is:</p>
<p>SELECT BRANCH_NAME FROM APP_BRANCH START WITH BRANCH_ID = ? CONNECT BY PRIOR PARENT_ID = BRANCH_ID</p>
<p>Error: ORA-00976: Specified pseudocolumn or operator not allowed here<br />
Any pointers or help appreciated. Also, what could be an alternative ANSI query?</p>
<p>Abhilesh</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Jellema</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5898</link>
		<dc:creator>Lucas Jellema</dc:creator>
		<pubDate>Sun, 13 Nov 2011 13:47:52 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5898</guid>
		<description><![CDATA[&lt;p&gt;Thanks Michiel for you suggestion for the alternative to CONNECT_BY_ROOT.&lt;/p&gt;
&lt;p&gt;Lucas&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Thanks Michiel for you suggestion for the alternative to CONNECT_BY_ROOT.</p>
<p>Lucas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Jellema</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5897</link>
		<dc:creator>Lucas Jellema</dc:creator>
		<pubDate>Sun, 13 Nov 2011 13:46:37 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5897</guid>
		<description><![CDATA[&lt;p&gt;Hi Cecil New,&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Lucas&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Hi Cecil New,</p>
<p>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.</p>
<p>Lucas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Jellema</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5896</link>
		<dc:creator>Lucas Jellema</dc:creator>
		<pubDate>Sun, 13 Nov 2011 13:44:54 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5896</guid>
		<description><![CDATA[&lt;p&gt;Hi Adamp,&lt;/p&gt;
&lt;p&gt;It does have a similar protection against endless loops - through the construction:&lt;/p&gt;
&lt;p&gt;Â &lt;/p&gt;
&lt;p style=&quot;margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;&quot;&gt;&lt;span style=&quot;font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;&quot;&gt;CYCLE name SET &lt;/span&gt;&lt;span style=&quot;font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;&quot;&gt;is_cycle&lt;/span&gt;&lt;span style=&quot;font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;&quot;&gt; TO &#039;Y&#039; DEFAULT &#039;N&#039;&lt;/span&gt;&lt;/p&gt;
&lt;p style=&quot;margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;&quot;&gt;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.&lt;/p&gt;
&lt;p style=&quot;margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;&quot;&gt;Â &lt;/p&gt;
&lt;p style=&quot;margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;&quot;&gt;Lucas&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Hi Adamp,</p>
<p>It does have a similar protection against endless loops &#8211; through the construction:</p>
<p>Â </p>
<p style="margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;"><span style="font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;">CYCLE name SET </span><span style="font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;">is_cycle</span><span style="font-family: &quot;Courier New&quot;; color: #003366; font-weight: bold;"> TO &#8216;Y&#8217; DEFAULT &#8216;N&#8217;</span></p>
<p style="margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;">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 &#8211; 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.</p>
<p style="margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;">Â </p>
<p style="margin-top: 0pt; margin-bottom: 0pt; margin-left: 0.38in; text-indent: -0.38in; text-align: left; direction: ltr; unicode-bidi: embed; vertical-align: baseline;">Lucas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cecil New</title>
		<link>http://technology.amis.nl/2009/09/01/oracle-rdbms-11gr2-goodbye-connect-by-or-the-end-of-hierarchical-querying-as-we-know-it/#comment-5895</link>
		<dc:creator>Cecil New</dc:creator>
		<pubDate>Thu, 03 Nov 2011 11:12:51 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=6104#comment-5895</guid>
		<description><![CDATA[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 &quot;revisions&quot; 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 &quot;don&#039;t revisit node&quot; approach?Â  Or can the new WITH syntax implement this approach?]]></description>
		<content:encoded><![CDATA[<p>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.<br />
By past, I mean &#8220;revisions&#8221; 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 &#8211; 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.<br />
Are there any feature in 11g that implement a &#8220;don&#8217;t revisit node&#8221; approach?Â  Or can the new WITH syntax implement this approach?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
