Plex 2E

Expand all | Collapse all

Create SQL Select/Omit in CA 2E same as DDS Select/omit

  • 1.  Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Aug 10, 2010 01:11 PM
    Hi

    There are no more performance issue to use select/omit in SQL if we use DB2 i5/OS R6.1 which has Create index with Where clause . This is exactly same as DDS Select/Omit with good performance.

    I was reading a article in http://wiki.2einfo.net/index.php?title=Using_SQL_with_2E which was saying dynamic and static selections are same in SQL.

    But it is not true if we use r6.1 which has Create INDEX with where clause to behave same as DDS static select/omit

    for perfromance improvement r6.1 will have IGNORE_DERIVED_INDEX *YES in QAQQINI

    I also tried creating own index in CA 2E and was working perfectly with no issues


    For mor info for Sql select/omit and performace please read below link

    http://www.dbmag.intelligententerprise.com/showArticle.jhtml?articleID=206800753&pgno=2

    Question to CA:

    I hope CA 2E will generate SQL source code correctly for SQL select/omit if we use r6.1

    Please confirm

    Thanks
    MD2E


  • 2.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Aug 31, 2010 10:13 AM
    Hi,

    You say "I hope CA 2E will generate SQL source code correctly for SQL select/omit if we use r6.1".

    When you say r6.1 I assume you are talking about OS V6R1, right?

    Please can you tell me what release of 2E you are using and what O/S you are using?

    I'd also like to see a, simple, example of:

    A ) What SQL source code is generated in your scenario now.
    B ) What SQL source code you would expect to see generated at V6R1.

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 3.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 17, 2010 02:29 PM
    Hi Simon

    Sorry for late reply

    Yes i did say OS V6R1

    Current company uses V5R4M0

    In these versions sleect omit criteria will not be created

    EXEC SQL
    CREATE UNIQUE INDEX LIBL.CusfileL1
    ON LIBL.Cusfile
    (CusnBr ASC
    ,Seqnbr ASC
    )
    END-EXEC

    In New version v6.1 code should be

    EXEC SQL
    CREATE UNIQUE INDEX LIBL.CusfileL1
    ON LIBL.Cusfile
    (CusnBr ASC
    Seqnbr ASC
    Cussts ASC)
    ) where Cussts='A'
    END-EXEC


    Note:
    The following example uses the new V6R1 Create Index syntax to create an SQL index that mimics a DDS Select/Omit Logical file.

    Be aware that the DB2 for i5/OS optimizer doesn't yet support use of sparse SQL indexes for queries (that is, those created with a WHERE clause). The sparse SQL indexes are only usable through native record-level access interfaces. Starting in V6R1, the new SQL Query Engine (SQE) Optimizer will use indexes associated with DDS key logical files that have derivations defined in the key specification when appropriate.

    CREATE INDEX STARTEST.BIGREVENUE ON STARTEST.ITEM_FACT (SUPPKEY ASC, QUANTITY * EXTENDEDPRICE ASC)

    WHERE QUANTITY * EXTENDEDPRICE > 100000


    Hope it helps

    Simon_Cockayne wrote:

    Hi,

    You say "I hope CA 2E will generate SQL source code correctly for SQL select/omit if we use r6.1".

    When you say r6.1 I assume you are talking about OS V6R1, right?

    Please can you tell me what release of 2E you are using and what O/S you are using?

    I'd also like to see a, simple, example of:

    A ) What SQL source code is generated in your scenario now.
    B ) What SQL source code you would expect to see generated at V6R1.

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 4.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 22, 2010 04:38 PM
    Hi MD2E,

    I am trying to test at i 6.1..

    Please can you elaborate on where you see this SQL, and any other detail to help me recreate.

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 5.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 02, 2010 07:18 PM
    Simon

    I thought i have shared the link for r6.1 OS400 for SQl enhacements



    the link was there in my post ..just copy and paste

    It is good to know that you got more info with help of Crispan

    Thanks
    Mohammed


  • 6.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 04, 2010 09:48 AM
    Hi Mohammed,

    You said "I thought i have shared the link for r6.1 OS400 for SQl enhacements".

    I don't see a link. Please can you clarify?

    Thanks,

    Simon

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 7.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 19, 2010 06:35 PM
    Dear Simon

    Please find teh below URL info.. please copy and paste on the browser and same has been given in my very first message

    http://www.dbmag.intelligententerprise.com/showArticle.jhtml?articleID=206800753&pgno=2

    Simon_Cockayne wrote:

    Hi Mohammed,

    You said "I thought i have shared the link for r6.1 OS400 for SQl enhacements".

    I don't see a link. Please can you clarify?

    Thanks,

    Simon

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 8.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 22, 2010 03:09 PM
    Thanks!

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 9.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 17, 2010 03:10 PM
    Hi Simon,

    This thread is quite interesting to me. I have spent a lot of time automating the replacement of DDS PF & LF source with DDL. There are still (at i 6.1) some things that cannot be replaced, but I am able to stop them from being replaced with TABLE entries. Because of limitations in the QSQGNDDL API, I am currently unable to replace Select/Omit LF's either. My TABLE/INDEX Record Format Level Identifiers match the original PF/LF, so I have no recompiles required, and it all works very well.

    Anyway, I end up with TABLE and INDEX objects instead of PF & LF, and I use them with RPG Record Level Access. There is another thread where I discuss what I am doing it quite some detail, so I won't repeat it here.

    But, it seems to me that there is no reason for 2E to not just generated DDL for all PF (TABLES). Including the RCDFMT clause would be required to make them work with the RPG (maybe COBOL) generators properly. The same goes for LF's (INDEX's). Obviously you would have to omit Joins, but I don't think there are any others that could not be generated as DDL.

    If 2E generated DDL for the TABLE/INDEX, then there would be a good improvement in the database from a modernization perspective.

    In the meantime, I'm quite willing to share what I'm doing :)

    Crispin.


  • 10.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 22, 2010 04:41 PM
    Hi Crispin,

    Thanks for the offer of sharing what you are up to.

    I am going to send you an email to try to arrange a time where you can show me what you have done and why...and let's figure out what could be, potentially done on the 2E side to assist.

    P.s. Does i 7.1 make it any easier?

    Cheers,

    Simon

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 11.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 29, 2010 02:41 PM
    Hi MD2E, Hi Crispin,

    First off, let me say a huge thank you to Crispin for spending time yesterday on a super-fruitful call on all things SQL. I.e. Where he is, what's possible with the OS, where he wants to be...and how 2E might help carry him (and others) there.

    Second, MD2E, I can now create the SQL you are seeing using 2E 8.5 on i 6.1.

    Here's my snippet of QSQLSRC for a RSQ ,SQL access path (Table access) with Static Select criteria on one of the attributes.
    EXEC SQL                                
      CREATE UNIQUE INDEX SBC85SQL.UUAFREL2I
             ON SBC85SQL.UUAFREP            
            (AFAGCD       ASC               
            ,AFAHCD       ASC               
            ,AFAICD       ASC               
            )                               
    END-EXEC    
    Clearly it does not add the Where clause, to specify the select in the creation of the index.

    We’ll also need to adjust the generation of the program source, to remove the programmatic selection; note the AND clause for AFAHTX in the SELECT statement below:
    C/EXEC SQL                                       
    C+     DECLARE UUAFREL2XCSR CURSOR FOR           
    C+       SELECT * FROM UUAFREP                   
    C+           WHERE (AFAGCD     >  :AFAGCD        
    C+           OR    (AFAGCD     =  :AFAGCD    AND 
    C+                  AFAHCD     >  :AFAHCD       )
    C+           OR    (AFAGCD     =  :AFAGCD    AND 
    C+                  AFAHCD     =  :AFAHCD    AND 
    C+                  AFAICD     >= :AFAICD       )
    C+                 )                             
    C+ AND ( ( AFAHTX = 'A'
    C+ )
    C+ )
                           C+       ORDER BY  AFAGCD        ASC,            C+                 AFAHCD        ASC,            C+                 AFAICD        ASC             C/END-EXEC   
    P.s. Thanks to Crispin we now have an enhancement request 19719092-2.

    The thinking is that this enhancement request covers:

    1.
    Allow model to generate DDL for Table and Index objects.
    2.
    DDL should include RCDFMT clause (we believe only supported from i6.1).
    3.
    Where LF has select/omit, add a Where clause (we believe only supported from i6.1).
    4.
    Allow RPG Record Level Access to such Tables/Indexes, i.e. you could regenerate a DDS PF and LF to SQL and not even have to recompile the RPG program that had worked with DDS! (If it didn’t have Select/Omit, see below).
    5.
    Adjust the generation of the program source, to remove the programmatic selection, since it can now be specified in the index.

    Feedback is warmly welcomed.

    Cheers,

    Simon


    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 12.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 29, 2010 03:20 PM
    Hi,

    Whoops!

    In a subsequent discussion with Crispin, he has wisely pointed out that I made a mistake, i.e. the programmatic selection needs to remain, then the SQL engine will pick up the appropriate index.

    Cheers,

    Simon


  • 13.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 29, 2010 03:47 PM
    Hi Simon,

    The common wisdom is to always access the TABLE from SQL. The SQL Engine is much smarter than I can ever be, at least at Data Access :)

    The Programmatic selection should remain in the DSPFIL Source code. The SQL Database engine will see the SQL Request, and say to itself that looks like this INDEX I have, I will use that to access the data.

    In fact, you will find that for SQLRPG you cannot SELECT * FROM INDEX. In fact, you can't SELECT * from an INDEX period. It is sometimes Ok to SELECT * FROM a VIEW, because the VIEW may have User Defined functions that create fields, and so on.

    But, for the 2E SQL Data Access, I wouldn't do much with it at all. Leave it be and let the system handle it. Now, if it was selecting the records out after it read them, I would say that was a problem, but because it uses a WHERE clause, all will be good and the INDEX will (should) be used.

    Now, for RPG RLA (Record Level Access), I would use the INDEX directly.

    I was playing around with the SQL Generator, and I see that the UUAFREL2 is generated as a VIEW. Then an INDEX is created, UUAFREL2I.

    In my world, UUAFREL2 would be the INDEX code.

    Here is what my INDEX Code looks like for the RTV Index over my Customer file (CCADREP).
    CREATE UNIQUE INDEX CRPU551GEN/CCADREL0           
      ON CRPU551GEN/CCADREP ( CUST_NUMBER ASC )       
      RCDFMT @ADREAR ;                                
                                                      
    LABEL ON INDEX CRPU551GEN/CCADREL0                
      IS 'Customer                  Retrieval index' ;
    Now, my DDL for the CCADREP TABLE looks like this.
    CREATE TABLE CRPU551GEN/CCADREP (                
    Cust_Number FOR COLUMN                           
      ADADCD CHAR(3) CCSID 37 NOT NULL DEFAULT '' ,  
    Cust_Name FOR COLUMN                             
      ADABTX CHAR(25) CCSID 937 NOT NULL DEFAULT '' ,
    Cust_Street FOR COLUMN                           
      ADACTX CHAR(20) CCSID 937 NOT NULL DEFAULT '' ,
    Cust_Extra_Line FOR COLUMN                       
      ADADTX CHAR(25) CCSID 937 NOT NULL DEFAULT '' ,
    Cust_City FOR COLUMN                             
      ADAETX CHAR(17) CCSID 937 NOT NULL DEFAULT '' ,
    Cust_State FOR COLUMN                            
      ADAFTX CHAR(2) CCSID 37 NOT NULL DEFAULT '' ,  
    Cust_Country FOR COLUMN                          
      ADQMCD CHAR(3) CCSID 37 NOT NULL DEFAULT '' ,  
    Cust_Zipcode FOR COLUMN                          
      ADAGTX CHAR(9) CCSID 37 NOT NULL DEFAULT '' ,  
    DUNS_ID FOR COLUMN                               
      ADDBTX CHAR(9) CCSID 37 NOT NULL DEFAULT '' )  
                                                     
      RCDFMT @ADREAT    ;                            
    
    LABEL ON TABLE CRPU551GEN/CCADREP               
      IS 'Customer                  Physical file' ;
                                                    
    LABEL ON COLUMN CRPU551GEN/CCADREP              
    ( ADADCD IS 'Cust                Number' ,      
      ADABTX IS 'Cust Name' ,                       
      ADACTX IS 'Cust Street' ,                     
      ADADTX IS 'Cust Extra Line' ,                 
      ADAETX IS 'Cust City' ,                       
      ADAFTX IS 'Cust State' ,                      
      ADQMCD IS 'Cust                Country' ,     
      ADAGTX IS 'Cust                Zipcode' ,     
      ADDBTX IS 'DUNS ID' ) ;                       
                                                    
    LABEL ON COLUMN CRPU551GEN/CCADREP              
    ( ADADCD TEXT IS 'Cust Number' ,                
      ADABTX TEXT IS 'Cust Name' ,                  
      ADACTX TEXT IS 'Cust Street' ,                
      ADADTX TEXT IS 'Cust Extra Line' ,            
      ADAETX TEXT IS 'Cust City' ,                  
      ADAFTX TEXT IS 'Cust State' ,                 
      ADQMCD TEXT IS 'Cust Country' ,               
      ADAGTX TEXT IS 'Cust Zipcode' ,               
      ADDBTX TEXT IS 'DUNS ID' ) ;
    So, I have a little more than you do, as I think the UUAFREP is probably defining the long names directly.

    I need the short internal RPG like names so that this will all work with RPG RLA. The DDL for the file I show works with the 2E Generated RPG Code, as if it was a DDS LF.

    I get this for my test file in my test model
    EXEC SQL                                                     
      CREATE TABLE CBTEMPSQL.CUSTOMER (                          
          CUSTOMER_CODE CHAR(6) NOT NULL WITH DEFAULT            
         ,CUSTOMER_NAME CHAR(25) NOT NULL WITH DEFAULT           
         ,CUSTOMER_ADDRESS CHAR(25) NOT NULL WITH DEFAULT        
         ,CUSTOMER_CODE______001045 CHAR(6) NOT NULL WITH DEFAULT
         ,ALLOW_IN_COMPUTE_EXPRESSI CHAR(1) NOT NULL WITH DEFAULT
         ,UNUSED_FIELD CHAR(25) NOT NULL WITH DEFAULT            
         ,LONG_KEY CHAR(500) NOT NULL WITH DEFAULT               
                                             )                   
    END-EXEC                                                     
    EXEC SQL                                                        
      COMMENT ON TABLE CBTEMPSQL.CUSTOMER IS                        
         'Customer                  Physical file'                  
    END-EXEC                                                        
                                                                    
    EXEC SQL                                                        
      COMMENT ON CBTEMPSQL.CUSTOMER (                               
          CUSTOMER_CODE IS 'Customer Code'                          
         ,CUSTOMER_NAME IS 'Customer Name'                          
         ,CUSTOMER_ADDRESS IS 'Customer Address'                    
         ,CUSTOMER_CODE______001045 IS 'Customer Code'              
         ,ALLOW_IN_COMPUTE_EXPRESSI IS 'Allow in Compute Expression'
         ,UNUSED_FIELD IS 'Unused Field'                            
         ,LONG_KEY IS 'Long Key'                                    
                                    )                               
    END-EXEC                                                        
    EXEC SQL                                                        
      LABEL ON TABLE CBTEMPSQL.CUSTOMER IS                          
         'Customer                  Physical file'                  
    END-EXEC                                                        
                                                                    
    EXEC SQL                                                        
      LABEL ON CBTEMPSQL.CUSTOMER (                                 
          CUSTOMER_CODE IS 'Customer Code'                          
          ,CUSTOMER_NAME IS 'Customer Name'                       
          ,CUSTOMER_ADDRESS IS 'Customer Address'                 
          ,CUSTOMER_CODE______001045 IS 'Customer Code'           
          ,ALLOW_IN_COMPUTE_EXPRESSI IS 'Allow in Expression'     
          ,UNUSED_FIELD IS 'Unused Field'                         
          ,LONG_KEY IS 'Long Key'                                 
                                   )                              
     END-EXEC                                                     
     EXEC SQL                                                     
       LABEL ON CBTEMPSQL.CUSTOMER (                              
           CUSTOMER_CODE TEXT IS 'Customer Code'                  
          ,CUSTOMER_NAME TEXT IS 'Customer Name'                  
          ,CUSTOMER_ADDRESS TEXT IS 'Customer Address'            
          ,CUSTOMER_CODE______001045 TEXT IS 'Customer Code'      
          ,ALLOW_IN_COMPUTE_EXPRESSI TEXT IS 'Allow in Expression'
          ,UNUSED_FIELD TEXT IS 'Unused Field'                    
          ,LONG_KEY TEXT IS 'Long Key'                            
                                   )                              
     END-EXEC                                                     
    The slight difference is that I have the FOR COLUMN clause to define the Short Names. The TABLE is also called CUSTOMER, and it should (would be in my perfect world) be called UUACREP. That may be another setting somewhere, I haven't used SQL in 2E much...

    I hope this helps you out. It's a little bit more tricky than it first looked, but hopefully not insurmountable!

    Thanks,

    Crispin.


  • 14.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Sep 30, 2010 10:11 AM
    Aha!

    YSQLVNM = *DDS is what I was after to get the TABLE named the way I want it. Now I get the original DDS Name for the TABLE. One out of the way already!

    Manual, what manual :)

    Crispin.


  • 15.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 02, 2010 07:15 PM
    Hi Simon and Crispin

    Thanks for taking this assignment.

    Yes. We should leave selection/omliu criteria when we use SQL. This is currenlt not supported in any of the versions in os othar than r6.1

    Do we have any batch readyt for this fix ?

    Thanks once again

    Simon
    Do you have your email id so that i have more researches on SYNON need you guys help

    MD2E


  • 16.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 04, 2010 09:47 AM
    Hi there MD2E,

    It's my pleasure to help you guys investigate SQL enhancements.

    I should make it clear that any discussion or investigation does NOT guarantee if/when any changes will be made in the product.

    There is currently no fix ready and no estimate.

    My email address is in my signature below.

    I hope to continue to work with you and Crispin and any other interested customers in this area.

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com


  • 17.  RE: Create SQL Select/Omit in CA 2E same as DDS Select/omit

    Posted Nov 19, 2010 06:32 PM
    Hi Simon

    Thanks for your reply.
    I saw your notes from one of the above replies

    So here you mentioned number 3 which is taken care of select Omit Criteria and the enhancement request is as below

    Yes i understand, fix will not be determined.. just let me know in case the mentioned request fix is available once ready
    Thx

    P.s. Thanks to Crispin we now have an enhancement request 19719092-2.

    The thinking is that this enhancement request covers:

    1. Allow model to generate DDL for Table and Index objects.
    2. DDL should include RCDFMT clause (we believe only supported from i6.1).
    3. Where LF has select/omit, add a Where clause (we believe only supported from i6.1).
    4. Allow RPG Record Level Access to such Tables/Indexes, i.e. you could regenerate a DDS PF and LF to SQL and not even have to recompile the RPG program that had worked with DDS! (If it didn’t have Select/Omit, see below).
    5. Adjust the generation of the program source, to remove the programmatic selection, since it can now be specified in the index.

    Feedback is warmly welcomed.

    Cheers,

    Simon






    Simon_Cockayne wrote:

    Hi there MD2E,

    It's my pleasure to help you guys investigate SQL enhancements.

    I should make it clear that any discussion or investigation does NOT guarantee if/when any changes will be made in the product.

    There is currently no fix ready and no estimate.

    My email address is in my signature below.

    I hope to continue to work with you and Crispin and any other interested customers in this area.

    Cheers,

    Simon Cockayne
    CA Technologies
    Principal Software Engineer
    CA Subject Matter Expert
    Tel: +1-703-708-3042
    Simon.cockayne@ca.com