Re: Looking for file structure details

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Welcome to SQL...

You don't get to decide "how" to return data.  You only get to decide
"what" to return.

That being said, Vern is right.  Run your query through visual explain and
see what it says. Pay particular attention to the "recommended indexes"

Also, read this:  IBM DB2 for i Indexing methods and strategies.
https://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sys_wp_db2_i_indexing_methods_strategies

It will help you to understand how to build the perfect index.

But, even if you have the perfect index, the QE may not use it.  That's
just how SQL works.

Charles

On Fri, Jun 26, 2015 at 6:27 PM, John R. Smith, Jr. <
smith5646midrange@xxxxxxxxx> wrote:

> I'm still in pain and frustrated.
>
> It appears that I can't use this index in imbedded SQL in an SQLRPGLE
> program or in STRSQL and if I use the table, the debugger appears to ignore
> the index because the joblog says it used arrival sequence to build the
> select from.
>
> Do I have something else wrong or do I need to give up and go back to my
> DDS
> built archive file?
>
> -----Original Message-----
> From: John R. Smith, Jr. [mailto:Smith5646midrange@xxxxxxxxx]
> Sent: Friday, June 26, 2015 1:50 PM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: Looking for file structure details
>
> I see the problem.
>
> When I do STRSQL and prompt the CREATE INDEX command (I am not super fluent
> with SQL so I always prompt and fill in the blanks), it does not allow the
> where clause but if I type it, it allows it.  The query error you mention
> is
> apparently because of the "unsupported" where clause because if I remove
> it,
> QRKQRY is happy again.  It would appear that IBM needs to get their tools
> (both STRSQL and WRKQRY) up to date with what they allow.
>
> Now that I can prove that I can create an SQL index with the where clause
> and key, I will push again for creating the index with SQL over the
> existing
> table.  I may not have the rope to pull on but I can argue that the
> original
> table is SQL based so the "logical" should be also.
>
> Thanks everyone for bearing with me on this.  It was somewhat painful and
> frustrating to get to this point but isn't that how all good designs are
> created...back and forth until you get it right? :)
>
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> rob@xxxxxxxxx
> Sent: Friday, June 26, 2015 1:27 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Looking for file structure details
>
> create index mylib.myindex
> on mylib.mytable (field4)
> where field3='X'
> rcdfmt MYTABLERCD add all columns
>
> INSERT INTO ROB.MYTABLE VALUES('A', 'B', 'X', 1) INSERT INTO ROB.MYTABLE
> VALUES('C', 'D', 'X', 2) INSERT INTO ROB.MYTABLE VALUES('E', 'F', 'A', 3)
>
> CPYF FROMFILE(ROB/MYINDEX) TOFILE(*PRINT)
>
> RCDNBR  *...+... 1 ...+... 2 ...+... 3
>      1  A         B         X         1
>      2  C         D         X         2
>
> Here's some RPG:
> FMYINDEX   IF   E             DISK
>  /free
>   dou %eof(myindex);
>     read myindex;
>     if not %eof(myindex);
>       dsply field4;
>     endif;
>   enddo;
>   *inlr=*on;
>   return;
>  /end-free
>
> When you execute it you will see:
> DSPLY  1
> DSPLY  2
>
> This is a good thing.  This should pass all RPG tests.  At least those that
> use RLA or traditional Record Level Access methods by RPG.
>
> Now, I AM having one sizeable problem.  When I use RUNQRY
> FILE(MYLIB/MYINDEX) against that file I am getting:
> QRY1045 - File MYINDEX in ROB cannot be queried.
> CPD4360 - Queried file MYINDEX in ROB not data base file or is an SQL
> derived key index.
>
> And STRSQL, select * from rob.myindex is generating
> SQL7011 - MYINDEX in ROB not table, view, or physical file.
>
> WRKQRY is generating
> QRY1089 - Error CPD4360-00 in query definition.
>
> I don't recall running into all these limitations before.
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
> to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   "John R. Smith, Jr." <smith5646midrange@xxxxxxxxx>
> To:     "'Midrange Systems Technical Discussion'"
> <midrange-l@xxxxxxxxxxxx>
> Date:   06/26/2015 12:49 PM
> Subject:        RE: Looking for file structure details
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> I'm still missing something in your example.
>
> Let's create a simple example and then you can provide the exact missing
> CREATE command.
>
> Table is created with the following.
>
> CREATE TABLE MYLIB/MYTABLE
> (
>   FIELD1 CHAR (10),
>   FIELD2 CHAR (10),
>   FIELD3 CHAR (10),
>   FIELD4 CHAR (10),
>   PRIMARY KEY (FIELD1, FIELD2)
> )
> RCDFMT MYTABLERCD
>
> How do I create a view/index/whatever with only records where FIELD3 = 'X'
> and Ordered by FIELD4.
>
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> rob@xxxxxxxxx
> Sent: Friday, June 26, 2015 9:02 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Looking for file structure details
>
> You CAN create an index with a WHERE clause.  IBM specifically made this to
> eliminate 99% of the arguments people had against SQL.
> Sample:
> Vendor creates table (let's call it IIM for an item master table).  Vendor
> puts no key on the table.  Table has an active record column (IID). Vendor
> creates a logical file in DDS like this
> R IPI100IM                  PFILE(IIM       )
> K IPROD
> S IID                       COMP(EQ 'IM')
> Of course the vendor is an a$$ who thinks their program logic will ensure
> there are no duplicate keys and whatnot.
>
> Several releases ago IBM came up with this in sql
>
> create index rob.iiml01
> on erplxf.iim (iprod)
> where iid='IM'
> rcdfmt IPI100IM add all columns
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
> to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe,
> or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
> moment to review the archives at http://archive.midrange.com/midrange-l.
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe,
> or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
> moment to review the archives at http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.