<?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>topic Re: SELECT WHERE IN issue in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670574#M616529</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Ryan,&lt;/P&gt;&lt;P&gt;Not sure that you have your answers but will respond anyways.&lt;/P&gt;&lt;P&gt;To answer your questions:&lt;/P&gt;&lt;P&gt;1- haven't seen anywhere where it said which table should go first, I'm confident it doesn't matter.&lt;/P&gt;&lt;P&gt;2-there should be no difference in how you coded your qmart where condition.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To improve upon your code:&lt;/P&gt;&lt;P&gt; - Select your data into Table, rather than appending table, Into Table is more efficient&lt;/P&gt;&lt;P&gt;- it is better to have an inner join than bring back a ton of data, as it puts load on the network, there are always exceptions but this is the norm. your statement is not complex, so your join is fine&lt;/P&gt;&lt;P&gt;- as mentioned by another response, a secondary index would make your program fly. Both your Where conditions are on non-key fields and your performance suffers greatly I'm sure. You would need an index created with qmart and vbeln in that order. Your Basis team should be able to confirm the benefit of this index. This should not be an option, given the size of the table. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The non-key fields on the Where clause is your biggest issue. Second is the Appending table. Make that change as well.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hope this helps.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Filler&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 14 Sep 2007 03:35:36 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2007-09-14T03:35:36Z</dc:date>
    <item>
      <title>SELECT WHERE IN issue</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670570#M616525</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi experts,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I am having performance issue regarding this statement:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt; SELECT zfc_join~awb_id&lt;/P&gt;&lt;P&gt;   APPENDING TABLE i_waybill_ids&lt;/P&gt;&lt;P&gt;   FROM zfc_join INNER JOIN qmel&lt;/P&gt;&lt;P&gt;     ON zfc_join&lt;SUB&gt;qmnum = qmel&lt;/SUB&gt;qmnum&lt;/P&gt;&lt;P&gt;    FOR ALL ENTRIES IN r_vbeln_temp&lt;/P&gt;&lt;P&gt;   WHERE qmart IN (c_dm,c_dv)&lt;/P&gt;&lt;P&gt;     AND qmel~vbeln EQ r_vbeln_temp-low.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;*Additional Notes:&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;1. QMEL contains 10 million+ records. ZFC_JOIN contains 200,000+ records.&lt;/P&gt;&lt;P&gt;2. Changed the range selection from QMEL~VBELN IN r_vbeln_temp to the codes above due&lt;/P&gt;&lt;P&gt;to a short dump error when the range is too big.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;Questions / clarification needed:&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;1. Does the placement of the join tables matters? That is,&lt;/P&gt;&lt;P&gt;    "zfc_join INNER JOIN qmel" is different from &lt;/P&gt;&lt;P&gt;    "qmel INNER JOIN zfc_join"&lt;/P&gt;&lt;P&gt;2. Does the command "qmart IN (c_dv,c_dm)" different from &lt;/P&gt;&lt;P&gt;    qmart EQ c_dv OR qmart EQ c_dm? Which is faster?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Please help out. Thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 28 Aug 2007 09:40:01 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670570#M616525</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-08-28T09:40:01Z</dc:date>
    </item>
    <item>
      <title>Re: SELECT WHERE IN issue</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670571#M616526</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi chan,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Definitely the following selection code gives big performance issues because u r u using joins conditions with where clause the fields are &amp;lt;b&amp;gt;non-key fields&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You can try this way.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Select QMNUM &lt;/P&gt;&lt;P&gt;  from QMEL into table tbl_qmel&lt;/P&gt;&lt;P&gt;where QMART eq c_dm or&lt;/P&gt;&lt;P&gt;          QMART c_dv  and&lt;/P&gt;&lt;P&gt;          Vbeln  in r_vbeln_temp-vbeln.&lt;/P&gt;&lt;P&gt;If sy-subrc = 0.&lt;/P&gt;&lt;P&gt;Sort tbl_qmel.&lt;/P&gt;&lt;P&gt;Endif.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;NOTE :&amp;lt;/b&amp;gt; in the above select statement is also gives performance issue bec fields using in &amp;lt;b&amp;gt;where clause are QMART and VBELN are non-key fields in table QMEL.&amp;lt;/b&amp;gt;.&lt;/P&gt;&lt;P&gt;If you want increase performance you have to create &amp;#145;&amp;lt;b&amp;gt;Secondary index&amp;#146;&amp;lt;/b&amp;gt;- for QMART and VBELN for tabel QMEL&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If not tbl_qmel[] is initial.&lt;/P&gt;&lt;P&gt;Select awb_id&lt;/P&gt;&lt;P&gt;  From zfc_join&lt;/P&gt;&lt;P&gt;APPENDING TABLE i_waybill_ids&lt;/P&gt;&lt;P&gt;For all entries in tbl_qmel&lt;/P&gt;&lt;P&gt;Where qmnum = tbl_qmel-qmnum.&lt;/P&gt;&lt;P&gt;Endif.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hope you will get some idea with above explanation.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reward with points if it is helpful.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Vijay&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 28 Aug 2007 10:52:08 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670571#M616526</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-08-28T10:52:08Z</dc:date>
    </item>
    <item>
      <title>Re: SELECT WHERE IN issue</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670572#M616527</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;For joins you must check the fields (where condition and on-condition) of the joined tables and the whether they appear indexes, this information should be added.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The question is always, is it possible to select effiecently with the where condition from on table and join the next table efficiently with the on-condition maybe plus further where-fields.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What are thre indexes on QMEL and on ZFC_Join (why is the table called join, is it a view).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Siegfried &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;P.S: I don't have time to look up this information by myself.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 28 Aug 2007 11:12:37 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670572#M616527</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-08-28T11:12:37Z</dc:date>
    </item>
    <item>
      <title>Re: SELECT WHERE IN issue</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670573#M616528</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Ryan,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This code is not good in terms of performance..&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT qmnum&lt;/P&gt;&lt;P&gt;FROM qmel&lt;/P&gt;&lt;P&gt;INTO TABLE tab_qmel&lt;/P&gt;&lt;P&gt;FOR ALL ENTRIES IN r_vbeln_temp&lt;/P&gt;&lt;P&gt;WHERE vbeln EQ r_vbeln_temp-low.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If sy-subrc EQ 0&lt;/P&gt;&lt;P&gt;AND NOT tab_qmel[] IS INITIAL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT qmnum&lt;/P&gt;&lt;P&gt;             awb_id&lt;/P&gt;&lt;P&gt;             ....&lt;/P&gt;&lt;P&gt;FROM zfc_join&lt;/P&gt;&lt;P&gt;INTO TABLE tab_zfc&lt;/P&gt;&lt;P&gt;FOR ALL ENTRIES IN tab_qmel&lt;/P&gt;&lt;P&gt;WHERE ( qmart EQ c_dm&lt;/P&gt;&lt;P&gt;OR           qmart EQ c_dv )&lt;/P&gt;&lt;P&gt;AND qmnum EQ tab_qmel-qmnum.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks and Best Regards,&lt;/P&gt;&lt;P&gt;Vikas Bittera.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;**&lt;STRONG&gt;Reward if useful&lt;/STRONG&gt;**&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 30 Aug 2007 17:30:05 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670573#M616528</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-08-30T17:30:05Z</dc:date>
    </item>
    <item>
      <title>Re: SELECT WHERE IN issue</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670574#M616529</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Ryan,&lt;/P&gt;&lt;P&gt;Not sure that you have your answers but will respond anyways.&lt;/P&gt;&lt;P&gt;To answer your questions:&lt;/P&gt;&lt;P&gt;1- haven't seen anywhere where it said which table should go first, I'm confident it doesn't matter.&lt;/P&gt;&lt;P&gt;2-there should be no difference in how you coded your qmart where condition.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To improve upon your code:&lt;/P&gt;&lt;P&gt; - Select your data into Table, rather than appending table, Into Table is more efficient&lt;/P&gt;&lt;P&gt;- it is better to have an inner join than bring back a ton of data, as it puts load on the network, there are always exceptions but this is the norm. your statement is not complex, so your join is fine&lt;/P&gt;&lt;P&gt;- as mentioned by another response, a secondary index would make your program fly. Both your Where conditions are on non-key fields and your performance suffers greatly I'm sure. You would need an index created with qmart and vbeln in that order. Your Basis team should be able to confirm the benefit of this index. This should not be an option, given the size of the table. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The non-key fields on the Where clause is your biggest issue. Second is the Appending table. Make that change as well.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hope this helps.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Filler&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 14 Sep 2007 03:35:36 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/select-where-in-issue/m-p/2670574#M616529</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-09-14T03:35:36Z</dc:date>
    </item>
  </channel>
</rss>

