Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

SQ>SST = 42601

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    SQ>SST = 42601

    Well, what does your programmatic select statement look like? If you are using LIKE then perhaps trailing spaces are the culprit. These statements are different: Select * from partfile where mypart like '%ABC%' Select * from partfile where mypart like '%ABC%' Chris
    Tags: None
  • #2
    SQ>SST = 42601

    Nope. The SQL statement is constructed in a string with only the required spaces. There are no LIKE statements strictly vanilla type with a select 'fields' 'from' 'where' and 'order by'. I went so far as to copy the created statement sent to program 2 that works and moved it to the statement sent to program 3 and it failed just like the new one did. It fails on the prepare statement??? Of course the explanation in the IBM book was extremely helpful.

    Comment

    • #3
      SQ>SST = 42601

      You stated in English what the select statement looks like. I want to know what the system sees as the select statement, in the Prepare. Since this is a prepared statement, do you have variables coded in the "order by" clause for example? A picture is worth a thousand words. Give us some code. Regards, Chris

      Comment

      • #4
        SQ>SST = 42601

        Here is the sql statement sent to the program. Pleas note that when I cut and paste this to the interactive SQL and execute it it runs fine. Thanks for all the help.
        Code

        Comment

        • #5
          SQ>SST = 42601

          What's the definition of field G1trn@? And did you set the SQL date format to *ISO in the program? See the sample code below. Chris
          Code

          Comment

          • #6
            SQ>SST = 42601

            Chris; I put that SQL Set Options in the program and it went really weird on me. When I tried to set a break point at the prepare statement the program responded with a break point line greater than the number of lines in the program. I did get a different error this time, but I think it was actually the failure of the prepare statement that caused it. This time I got a 26501. The really strange thing is that if i call this program from a non SQL program it works just fine. It has got to have something to do with the relationship between the 2 SQL programs. Rochester has been working on this for almost 2 days now. They want us to start a trace on my program and on my co-worker's. I keep telling myself that this should work and have tried all sorts of permutations of code and it still baffles me. I would imagine that it is going to turn out to be something small and insignificant. I do appreciate the help. Bill

            Comment

            • #7
              SQ>SST = 42601

              This is going to sound TOTALLY goofy, Bill, but you seem to be at the end of your rope. From what I gather, you're sending a character variable from one program to the other with a formatted SQL statement in it, and executing it in the second program. Is the variable definition for the PARM exactly the same in both programs? Most importantly, are they both either VARYING or not VARYING? Just checking. Joe

              Comment

              • #8
                SQ>SST = 42601

                I have an application that uses one program to create an SQL statement sending it to a 2nd program that executes the SQL statement and displays data on the screen. The user may choose an option on any line of the subfile to display data pertaining to that line. Another SQL statement is created and sent as a parm to a 3rd program where it blows up. I get an SQLSTT of 42601 and an SQLCOD of -104 on the prepare statement. If I create the SQL statement in a dummy program and call the 3rd program it works fine. If I debug and copy the SQL statement to the interactive SQL it works fine. My co-worker is having a similar problem sending the SQL statement as a parm to a submitted job. If she sends it to an interactive job it runs OK but not in batch. My application is interactive. Any ideas as to what is going on? My co-worker has involved IBM yesterday and sent the DBMON file but as of yet we have heard nothing. You guys are usually faster than IBM. Go ahead and prove me right. TIA Bill Barnes The Pantry, Inc.

                Comment

                • #9
                  SQ>SST = 42601

                  Joe; That was the right question to ask. I have done this parm passing of a field called SQL_STATEMENT many times before and it was a 4096 field. One of the new applications had to be increased to a 6144. The new program was still at 4096. I would be willing to bet that the second parm was sneaking in at the very end and I never panned out to look at the end. As soon as I made the parm lengths equal everything worked as intended. Thanks for asking the right question. Bill Barnes

                  Comment

                  Previous template Next
                  Working...
                  X