<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Question Re: left outer join not working as expected in Technology Q&amp;A</title>
    <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833764#M4864607</link>
    <description>&lt;P&gt;In addition to Volker's answer...&lt;/P&gt;
&lt;P&gt;I am as confused as you are about the "expected behavior" of outer joins, but there are a couple of tricks that can help.&lt;/P&gt;
&lt;P&gt;First of all, AVOID any predicates in the ON clause that DO NOT have anything to do with the join. Here that means do not code "and oh.order_date &amp;gt;= '2013-10-01'" in the ON clause... sometimes these clauses do what you expect, other times (as Volker has explained) they do what other people expect.&lt;/P&gt;
&lt;P&gt;Second, use derived tables instead of the WHERE clause when you want to limit the rows from individual tables. Logically speaking, derived table expressions are calculated before the join clause, so they are a WONDERFUL way to divide and conquer complex requirements.&lt;/P&gt;
&lt;P&gt;CAVEAT EMPTOR: I have not tested the following code...&lt;/P&gt;
&lt;PRE&gt;select oh.customer_id, oh.order_number, oh.num_of_line_items, isNull( max( oli.line_number ), 0 ), oh.order_date  
  from ( SELECT * FROM order_header WHERE order_date &amp;gt;= '2013-10-01' ) oh 
       left outer join order_line_items oli 
       on oh.order_seq_num = oli.order_seq_num 
 group by oh.customer_id, oh.order_number, oh.num_of_line_items , oh.order_date;
&lt;/PRE&gt;

&lt;P&gt;Note: The SELECT * doesn't make the query any less efficient, but it DOES make the derived table much easier to code: you don't have to list the columns you need, the optimizer can figure that out without your help &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Some folks (like me) don't like using abbreviated alias names, so this suggestion is for you: You can use the base table name as an alias name for the derived table, something I often do when retrofitting derived tables into large existing queries...&lt;/P&gt;
&lt;PRE&gt;select order_header.customer_id, 
       order_header.order_number, 
       order_header.num_of_line_items, 
       isNull( max( order_line_items.line_number ), 0 ), 
       order_header.order_date  
  from ( SELECT * 
           FROM order_header 
          WHERE order_date &amp;gt;= '2013-10-01' 
       ) AS order_header 
       left outer join order_line_items  
       on order_header.order_seq_num = order_line_items.order_seq_num 
 group by order_header.customer_id,  
       order_header.order_number,  
       order_header.num_of_line_items,  
       order_header.order_date;
&lt;/PRE&gt;

&lt;P&gt;...so the outer select still refers to "order_header" even though it is now a derived table name.&lt;/P&gt;
&lt;P&gt;The query optimizer does a pretty good job of "flattening out" the queries where possible, when derived tables and views are involved (you can think of a derived table as a local view).&lt;/P&gt;</description>
    <pubDate>Wed, 12 Feb 2014 09:14:27 GMT</pubDate>
    <dc:creator>Breck_Carter</dc:creator>
    <dc:date>2014-02-12T09:14:27Z</dc:date>
    <item>
      <title>left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaq-p/13833762</link>
      <description>&lt;P&gt;this select doesn't return what i expect&lt;/P&gt;
&lt;DIV class="codehilite"&gt;&lt;PRE&gt;&lt;SPAN class="k"&gt;select&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;customer_id&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_number&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;num_of_line_items&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="k"&gt;isNull&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt; &lt;SPAN class="k"&gt;max&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;line_number&lt;/SPAN&gt; &lt;SPAN class="p"&gt;),&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;0&lt;/SPAN&gt; &lt;SPAN class="p"&gt;),&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt;  
&lt;SPAN class="k"&gt;from&lt;/SPAN&gt; &lt;SPAN class="n"&gt;order_header&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt; &lt;SPAN class="k"&gt;left&lt;/SPAN&gt; &lt;SPAN class="k"&gt;outer&lt;/SPAN&gt; &lt;SPAN class="k"&gt;join&lt;/SPAN&gt; &lt;SPAN class="n"&gt;order_line_items&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt; &lt;SPAN class="k"&gt;on&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_seq_num&lt;/SPAN&gt; &lt;SPAN class="o"&gt;=&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_seq_num&lt;/SPAN&gt; 
&lt;SPAN class="k"&gt;and&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt; &lt;SPAN class="o"&gt;&amp;gt;=&lt;/SPAN&gt; &lt;SPAN class="s1"&gt;'2013-10-01'&lt;/SPAN&gt;   
&lt;SPAN class="k"&gt;group&lt;/SPAN&gt; &lt;SPAN class="k"&gt;by&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;customer_id&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_number&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;num_of_line_items&lt;/SPAN&gt; &lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt;
&lt;/PRE&gt;&lt;/DIV&gt;


&lt;P&gt;it returns orders dated before 2013-10-01&lt;/P&gt;
&lt;P&gt;this select returns what i expect&lt;BR /&gt;
&lt;/P&gt;
&lt;DIV class="codehilite"&gt;&lt;PRE&gt;&lt;SPAN class="k"&gt;select&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;customer_id&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_number&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;num_of_line_items&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="k"&gt;isNull&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt; &lt;SPAN class="k"&gt;max&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;line_number&lt;/SPAN&gt; &lt;SPAN class="p"&gt;),&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;0&lt;/SPAN&gt; &lt;SPAN class="p"&gt;),&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt;  
&lt;SPAN class="k"&gt;from&lt;/SPAN&gt; &lt;SPAN class="n"&gt;order_header&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt; &lt;SPAN class="k"&gt;left&lt;/SPAN&gt; &lt;SPAN class="k"&gt;outer&lt;/SPAN&gt; &lt;SPAN class="k"&gt;join&lt;/SPAN&gt; &lt;SPAN class="n"&gt;order_line_items&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt; &lt;SPAN class="k"&gt;on&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_seq_num&lt;/SPAN&gt; &lt;SPAN class="o"&gt;=&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oli&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_seq_num&lt;/SPAN&gt;   
&lt;SPAN class="k"&gt;where&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt; &lt;SPAN class="o"&gt;&amp;gt;=&lt;/SPAN&gt; &lt;SPAN class="s1"&gt;'2013-10-01'&lt;/SPAN&gt;  
&lt;SPAN class="k"&gt;group&lt;/SPAN&gt; &lt;SPAN class="k"&gt;by&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;customer_id&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_number&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;num_of_line_items&lt;/SPAN&gt; &lt;SPAN class="p"&gt;,&lt;/SPAN&gt; &lt;SPAN class="n"&gt;oh&lt;/SPAN&gt;&lt;SPAN class="p"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;order_date&lt;/SPAN&gt;
&lt;/PRE&gt;&lt;/DIV&gt;


&lt;P&gt;note the order date qualifier is in the WHERE clause&lt;BR /&gt;
&lt;/P&gt;
&lt;P&gt;i thought i understood left outer joins, but now i'm confused&lt;/P&gt;</description>
      <pubDate>Tue, 11 Feb 2014 11:02:52 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaq-p/13833762</guid>
      <dc:creator>t1950</dc:creator>
      <dc:date>2014-02-11T11:02:52Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833763#M4864606</link>
      <description>&lt;P&gt;That's expected behaviour:&lt;/P&gt;
&lt;P&gt;The first query will return all rows from table &lt;EM&gt;order_header&lt;/EM&gt; (independent of the order_date) and join those of them with an according order_date &amp;gt;= 2013-10-01 to the according &lt;EM&gt;order_line_items&lt;/EM&gt;. So order headers before that date will show up without their items.&lt;/P&gt;
&lt;P&gt;I guess the misunderstanding has to do with the following:&lt;/P&gt;
&lt;P&gt;If you want to filter on the &lt;STRONG&gt;null-supplying side&lt;/STRONG&gt; (here on &lt;EM&gt;order_line_items&lt;/EM&gt;, say to restrict them to the first &lt;EM&gt;n&lt;/EM&gt; items per order header or the like), then you have to specify that condition in the join's ON clause - otherwise (i.e. in the WHERE clause) you usually will turn the left join into an inner join (a common mistake, cf. &lt;A href="http://sqlanywhere.blogspot.de/2014/02/characteristic-errors-revision-5.html"&gt;Breck's list of characteristic errors no. 1&lt;/A&gt;).&lt;/P&gt;
&lt;P&gt;But here you seem to want to filter on the &lt;STRONG&gt;preserved side&lt;/STRONG&gt;, and then you can simply use the WHERE clause as usual.&lt;/P&gt;
&lt;P&gt;(A further method to do so would be to use a derived table for &lt;EM&gt;order_header&lt;/EM&gt; with the according WHERE clause and left join that derived table to the &lt;EM&gt;order_line_items&lt;/EM&gt; table.)&lt;/P&gt;</description>
      <pubDate>Tue, 11 Feb 2014 11:41:27 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833763#M4864606</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2014-02-11T11:41:27Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833765#M4864608</link>
      <description>&lt;P&gt;FWIW: The "null-supplying side" problem is discussed here in this FAQ with a somewhat very similar title (and OP):&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;&lt;A href="http://sqlanywhere-forum.sap.com/questions/13293/left-outer-join-not-working-as-expected"&gt;left outer join not working as expected&lt;/A&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Note: This link is not a &lt;DEL&gt;self-join&lt;/DEL&gt; self-link:)&lt;/P&gt;</description>
      <pubDate>Tue, 11 Feb 2014 12:01:26 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833765#M4864608</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2014-02-11T12:01:26Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833764#M4864607</link>
      <description>&lt;P&gt;In addition to Volker's answer...&lt;/P&gt;
&lt;P&gt;I am as confused as you are about the "expected behavior" of outer joins, but there are a couple of tricks that can help.&lt;/P&gt;
&lt;P&gt;First of all, AVOID any predicates in the ON clause that DO NOT have anything to do with the join. Here that means do not code "and oh.order_date &amp;gt;= '2013-10-01'" in the ON clause... sometimes these clauses do what you expect, other times (as Volker has explained) they do what other people expect.&lt;/P&gt;
&lt;P&gt;Second, use derived tables instead of the WHERE clause when you want to limit the rows from individual tables. Logically speaking, derived table expressions are calculated before the join clause, so they are a WONDERFUL way to divide and conquer complex requirements.&lt;/P&gt;
&lt;P&gt;CAVEAT EMPTOR: I have not tested the following code...&lt;/P&gt;
&lt;PRE&gt;select oh.customer_id, oh.order_number, oh.num_of_line_items, isNull( max( oli.line_number ), 0 ), oh.order_date  
  from ( SELECT * FROM order_header WHERE order_date &amp;gt;= '2013-10-01' ) oh 
       left outer join order_line_items oli 
       on oh.order_seq_num = oli.order_seq_num 
 group by oh.customer_id, oh.order_number, oh.num_of_line_items , oh.order_date;
&lt;/PRE&gt;

&lt;P&gt;Note: The SELECT * doesn't make the query any less efficient, but it DOES make the derived table much easier to code: you don't have to list the columns you need, the optimizer can figure that out without your help &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Some folks (like me) don't like using abbreviated alias names, so this suggestion is for you: You can use the base table name as an alias name for the derived table, something I often do when retrofitting derived tables into large existing queries...&lt;/P&gt;
&lt;PRE&gt;select order_header.customer_id, 
       order_header.order_number, 
       order_header.num_of_line_items, 
       isNull( max( order_line_items.line_number ), 0 ), 
       order_header.order_date  
  from ( SELECT * 
           FROM order_header 
          WHERE order_date &amp;gt;= '2013-10-01' 
       ) AS order_header 
       left outer join order_line_items  
       on order_header.order_seq_num = order_line_items.order_seq_num 
 group by order_header.customer_id,  
       order_header.order_number,  
       order_header.num_of_line_items,  
       order_header.order_date;
&lt;/PRE&gt;

&lt;P&gt;...so the outer select still refers to "order_header" even though it is now a derived table name.&lt;/P&gt;
&lt;P&gt;The query optimizer does a pretty good job of "flattening out" the queries where possible, when derived tables and views are involved (you can think of a derived table as a local view).&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 09:14:27 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833764#M4864607</guid>
      <dc:creator>Breck_Carter</dc:creator>
      <dc:date>2014-02-12T09:14:27Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833766#M4864609</link>
      <description>&lt;P&gt;I would certainly suggest to use your first sample (well, I tend to use short alias names...) - that's exactly what I tried to hint at with my "&lt;EM&gt;(A further method to do so would be to use a derived table for...&lt;/EM&gt;" suggestion.&lt;/P&gt;
&lt;P&gt;I guess this method to "localize filters" via derived tables really helps to solve such problems.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 10:08:21 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833766#M4864609</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2014-02-12T10:08:21Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833767#M4864610</link>
      <description>&lt;P&gt;to Breck and Volker,&lt;/P&gt;
&lt;P&gt;Volker's explanation of when to use a qualifier in the where clause vs. in the join was very helpful.&lt;BR /&gt;
&lt;/P&gt;
&lt;P&gt;Breck's statement of "...AVOID any predicates in the ON clause that DO NOT have anything to do with the join.." makes a lot of sense and should make the conversion of *= much easier.  I tested Brecks' example of a derived table, and it does work as expected.  I also tested the select with a where clause (one of my original selects) to see which was faster.  The where clause came back must faster but it could be a result of caching after I tested the derived table select.  I will test both of these after the server "cools" down on  different days.&lt;/P&gt;
&lt;P&gt;Thanks for your help.&lt;/P&gt;
&lt;P&gt;Tom Mangano&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 13:27:04 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833767#M4864610</guid>
      <dc:creator>t1950</dc:creator>
      <dc:date>2014-02-12T13:27:04Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833768#M4864611</link>
      <description>&lt;P&gt;BTW,&lt;/P&gt;
&lt;P&gt;Both answers shed new light on outer joins.  Is it possible to accept both answers and close the question and how do I accept answers to close the question?&lt;/P&gt;
&lt;P&gt;Tom M&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 13:46:05 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833768#M4864611</guid>
      <dc:creator>t1950</dc:creator>
      <dc:date>2014-02-12T13:46:05Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833769#M4864612</link>
      <description>&lt;P&gt;CALL sa_flush_cache() will cool down the server... but the only guaranteed way to flush everything is to restart the executable.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 16:18:12 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833769#M4864612</guid>
      <dc:creator>Breck_Carter</dc:creator>
      <dc:date>2014-02-12T16:18:12Z</dc:date>
    </item>
    <item>
      <title>Re: left outer join not working as expected</title>
      <link>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833770#M4864613</link>
      <description>&lt;P&gt;No, you have to pick... and Volker is the one who actually answered the question &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 12 Feb 2014 16:19:48 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/left-outer-join-not-working-as-expected/qaa-p/13833770#M4864613</guid>
      <dc:creator>Breck_Carter</dc:creator>
      <dc:date>2014-02-12T16:19:48Z</dc:date>
    </item>
  </channel>
</rss>

