|
View previous topic :: View next topic
|
| Author |
Message |
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
Hi all,
I am getting an SQLCODE of +354 while multi fetching rows from a DB2 table. I've verified that the following things are proper.
1. datatypes of host variables matching with columns of the table
2. order of the host variables in INTO clause same as SELECT in cursor declaration
3. all null indicators are taken into account in the INTO clause.
I've used the get diagnostics statement and it is returning return_code = 0.
P.S. ROW_COUNT is not working for me here. 
Can someone please tell me if I am unaware of any other possible causes  |
|
| Back to top |
|
 |
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
Hi all,
The problem is solved. That was due to the naming of the null indicator variable in cobol.
If the host variable name is HOST-VAR-COL then the name of the null indicator should be HOST-VAR-COL-NULL. That solved the problem. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
If the host variable name is HOST-VAR-COL then the name of the null indicator should be HOST-VAR-COL-NULL
|
that is not true
you do need to follow rules of syntax.
glad your problem is fixed, but I doubt if you know what the problem was |
|
| Back to top |
|
|
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
[quote=dbzTHEdinosauer]that is not true[/quote]
But that was the only modification made to the program. It was suggested by a peer who had solved it the same way long back.
The table data is still the same. The query was working in SPUFI before solving +354 and after(If I may say) solving.
Can you pls elaborate more on your doubt? Have you ever coded something like I did and got away with it?  |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
1. you have not posted your SQL.
2. there is no requirement that the reference name for the null indicator be based on the reference name of the host variable receiving the row data.
3. you have/had something incorrect with your syntax if you received a 0 sql from the get diagnostics. rowcount should work if you provided a proper host variable.
without seeing your code, there is nothing I can add. I don't get away with things with DB2. I code according to syntax and suprise, suprise, I get my results.
Sorry, anyone who would buy (or sell) the BS that a null indicator needs to be named similarly to the host varible has a low level of db2 understanding. |
|
| Back to top |
|
|
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
| dbzTHEdinosauer wrote: |
I don't get away with things with DB2. I code according to syntax and suprise, suprise, I get my results.
|
I did not mean to offend you.
| Quote: |
| Sorry, anyone who would buy (or sell) the BS that a null indicator needs to be named similarly to the host varible has a low level of db2 understanding |
You said this about the best we have. 
No more statements/comments from me...... |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
Hi
From SQLCODE,
| Quote: |
+354 A ROWSET FETCH STATEMENT MAY HAVE RETURNED ONE OR MORE ROWS OF DATA. HOWEVER, ONE OR MORE WARNING CONDITIONS WERE ALSO ENCOUNTERED. USE THE GET DIAGNOSTICS STATEMENT FOR MORE INFORMATION REGARDING THE CONDITIONS
THAT WERE ENCOUNTERED
Attention: It is also possible that an end of data condition was detected.
SQLERRD3 and GET DIAGNOSTICS can be used to determine if all of the
requested rows were fetched or if a partial rowset was returned.
|
We have also encountered similar condition when we have FETCH having ROWSET in one of our programs.
Please find the above description. (Attention part)
If the ROWSET is defined for 50 rows and if we are having only 10 rows in the table then we would be getting the above SQLCODE, it is not an error and is a warning message.
In our shop, For both SQLCODE 0 and 354, we will continue and move the host variable values to the array.
Hope this helps, |
|
| Back to top |
|
|
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
| Suresh Ponnusamy wrote: |
| If the ROWSET is defined for 50 rows and if we are having only 10 rows in the table then we would be getting the above SQLCODE, |
This may not be true. Because we define ROWSET size as 1000 and use Multi-Fetch even if the query returns 2 rows. But +354 is not ususal for us.
| Quote: |
| In our shop, For both SQLCODE 0 and 354, we will continue and move the host variable values to the array |
In that case I think you will be missing some data which might exist in the table. Have you got a chance to verify the number of rows returned in the program and the number of rows returned while running in SPUFI? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| You said this about the best we have. |
Even the best at some place will not know everything. They do probably know a way to get a certain ("thing") done and follow the same mechanics each time they do this.
You might ask for the reference to the coding rule you learned about. It may be something implemented locally as standards envorcement.
If you post the problem definition and the code that needed work, we will be able to offer better suggestions. |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
Hi Bharath
We have the above (Moving to the array for both SQLCODE = 0 and +354) in all our programs and they are batch programs running everyday and we did not encountered any problems till today
. |
|
| Back to top |
|
|
|
|
