<?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: Sql from Direct Discovery in QlikView</title>
    <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621753#M437836</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;You're right in the first test the Calendar was a QlikView-Table. But we are able to put the Date-Dimensions into the fact table. But if we do this with every dimension we got fact-tables with many columns. We will do some tests and i will post an update when i got results.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 22 May 2014 14:57:41 GMT</pubDate>
    <dc:creator />
    <dc:date>2014-05-22T14:57:41Z</dc:date>
    <item>
      <title>Sql from Direct Discovery</title>
      <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621749#M437832</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;I started to check the DirectDiscovery Function and have a question to improve the by Direct Discovery generated Sql.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Example with two Tables:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Calendar:&lt;/P&gt;&lt;P&gt;Date,&lt;/P&gt;&lt;P&gt;Month,&lt;/P&gt;&lt;P&gt;Year&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;DirectDiscoveryTable:&lt;/P&gt;&lt;P&gt;Date&lt;/P&gt;&lt;P&gt;Implicit&lt;/P&gt;&lt;P&gt;Value&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The generated Sql looks like ' Select ... from ... where Date in (...,..&lt;SPAN style="font-size: 10pt; line-height: 1.5em;"&gt;)'&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;If the user select three years there are more then 1000 entries in the in-part. It's obvious why the Sql is generated like this, but it's not the fastest query.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'm looking for Ideas to improve the QlikView Application, so that the Direct Discovery function is able to build better queries.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your comments.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 25 Mar 2014 22:03:23 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621749#M437832</guid>
      <dc:creator />
      <dc:date>2014-03-25T22:03:23Z</dc:date>
    </item>
    <item>
      <title>Re: Sql from Direct Discovery</title>
      <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621750#M437833</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Torsten - great question, I have seen apps where the IN clause approaches 10000 entries which is really ugly. I will check with our dev folks, but in terms of general rdbms best practice, what would you suggest as a better mechanism?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 24 Apr 2014 16:00:49 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621750#M437833</guid>
      <dc:creator />
      <dc:date>2014-04-24T16:00:49Z</dc:date>
    </item>
    <item>
      <title>Re: Sql from Direct Discovery</title>
      <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621751#M437834</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Is there any field other than Date that can be used in IN-clause?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 24 Apr 2014 17:13:13 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621751#M437834</guid>
      <dc:creator>nagaiank</dc:creator>
      <dc:date>2014-04-24T17:13:13Z</dc:date>
    </item>
    <item>
      <title>Re: Sql from Direct Discovery</title>
      <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621752#M437835</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I think you have a table (fact table) in dbms and one or more tables in qlikview, in your case 2 tables&lt;/P&gt;&lt;P&gt;can you join the 2 tables in dbms? no, because calendar is a qlikview table; so you can only send a where clause to the dbms for selecting data from fact table; where Date in (.....) is the simpler solution. Perhaps a between would be better but it is more difficult to generate.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Don't know if using a single table (Calendar + DirectDiscoveryTable) in dbms can be useful or if using two tables in dbms&amp;nbsp; and a view for querying them in Qlikview can be useful.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;IMHO if you can stay on Qlikview side (I mean time to reload Qlik doc, hardware to support your big fact table, etc....) don't use direct query.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Another thing that could be usefut (from online help)&lt;/P&gt;&lt;P&gt;Native data-source syntax&lt;/P&gt;&lt;P&gt;By design, the DIRECT QUERY statement is data-source neutral for data sources that support SQL. For that reason, the same DIRECT QUERY statement can be used for different SQL databases without change. Direct Discovery generates database-appropriate queries as needed. &lt;/P&gt;&lt;P&gt;Native data-source syntax can be used when the user knows the database to be queried and wants to exploit database-specific extensions to SQL. Native data-source syntax is supported:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;As field expressions in DIMENSION and MEASURE clauses &lt;/LI&gt;&lt;LI&gt;As the content of the WHERE clause &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Examples:&lt;/P&gt;&lt;P&gt;&lt;SPAN class="Code"&gt;DIRECT QUERY &lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE class="jive-quote"&gt;&lt;P&gt;&lt;SPAN class="Code"&gt;DIMENSION Dim1, Dim2 &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class="Code"&gt;MEASURE &lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE class="jive-quote"&gt;&lt;P&gt;&lt;SPAN class="Code"&gt;NATIVE ('X % Y') AS X_MOD_Y &lt;/SPAN&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;/BLOCKQUOTE&gt;&lt;BLOCKQUOTE class="jive-quote"&gt;&lt;SPAN class="Code"&gt;FROM TableName&lt;/SPAN&gt; &lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN style="font-family: monospace;"&gt;DIRECT QUERY&lt;/SPAN&gt; &lt;/P&gt;&lt;BLOCKQUOTE class="jive-quote" style="font-family: monospace;"&gt;&lt;P&gt;DIMENSION Dim1, Dim2 &lt;/P&gt;&lt;P&gt;MEASURE X, Y &lt;/P&gt;&lt;P&gt;FROM TableName &lt;/P&gt;&lt;P&gt;WHERE NATIVE ('EMAIL MATCHES "\*.EDU"')&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 24 Apr 2014 18:07:05 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621752#M437835</guid>
      <dc:creator>maxgro</dc:creator>
      <dc:date>2014-04-24T18:07:05Z</dc:date>
    </item>
    <item>
      <title>Re: Sql from Direct Discovery</title>
      <link>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621753#M437836</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;You're right in the first test the Calendar was a QlikView-Table. But we are able to put the Date-Dimensions into the fact table. But if we do this with every dimension we got fact-tables with many columns. We will do some tests and i will post an update when i got results.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 22 May 2014 14:57:41 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Sql-from-Direct-Discovery/m-p/621753#M437836</guid>
      <dc:creator />
      <dc:date>2014-05-22T14:57:41Z</dc:date>
    </item>
  </channel>
</rss>

