ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Interpreting errors from embedded SQL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Interpreting errors from embedded SQL

    Hi Folks

    When you have embedded SQL in an SQLRPGLE program you'll sometimes get a message like so:

    Code:
    From module . . . . . . . . :   QSQFETCH                                    
    From procedure  . . . . . . :   CK_DEBUG                                    
    Statement . . . . . . . . . :   24002                                       
    To module . . . . . . . . . :   QSQFETCH                                    
    To procedure  . . . . . . . :   CK_DEBUG                                    
    Statement . . . . . . . . . :   24002                                       
    Message . . . . :   Result of SELECT more than one row.                     
    Cause . . . . . :   The result table of a SELECT INTO statement, a subquery,
    (etc.)

    There are several potential candidates in the program for this error - several SELECT INTOs that might return more than one row.

    I would like to understand if/how I can isolate the exact lines of code. Line 24002 doesn't correspond with anything remotely relevant in the source, whether you take it at face value or treat it as 240.02 - I've compiled the program and checked the source generated in QTEMP/QSQLTEMP1 and that doesn't have any such line either.

    The message doesn't indicate the key or the file or anything much of use.

    Is there a way to trace it?



  • #2
    Statement 24002 refers to module QSQFETCH, which is one of the IBM modules involved in executing SQL. So it doesn't correspond to your program. I find that quite annoying too.

    Are there earlier messages in the job log that may shed more light on it?

    How many select into statements does your program have? You could check the value of SQLCOD and/or SQLSTT after each one to look for this error.

    The only thing I can suggest is you test every one of the select into statements in your program and see if any might return multiple records. Maybe someone else will have a better idea.

    Comment


    • #3
      #1 rule, always check you SQLSTATE.

      That being said, I've been in your shoes before. I look at surrounding joblog entries and try to narrow it down. Sometimes I have to write addition statements to the joblog and check again later.

      Comment


      • #4
        Greetings William

        Is it possible that the compiler listing can show you line 24002? I have occasionally found SQL errors in what the computer is actually running.... then again, sometimes not.

        I'm also thinking that maybe SELECT INTO DISTINCT or SELECT INTO UNIQUE kind of thing could be used instead of a simple SELECT INTO. Not being sure of the purpose of the program you're working with, I don't know about what the output table restrictions (or uses) might be either.


        Best Regards and Good Luck,
        Fred Williams

        Comment


        • #5
          Thanks guys.

          It seems the consensus is that conventional debugging techniques are still needed to find where the error is occurring.

          Comment

          Working...
          X