We are currently in development stage using BO against DB2 MVS Tables. I am still tweaking the first Universe and when I create reports I am having the following problem. I can run reports that return correct data with no errors, but when I go into the Query Panel to view the SQL and press the Check SQL button I get the following message:
Parsing Result
[IBM][CLI Driver][DB2] SQL0501N The cursor specified in a FETCH or CLOSE statement is not open.
SQLSTATE=24501
I have not worked with DB2 very much in the past and I am not familiar with
what is causing this. Please provide me with some insight.
We are currently in development stage using BO against DB2 MVS Tables. I am still tweaking the first Universe and when I create reports I am having the following problem. I can run reports that return correct data with no errors, but when I go into the Query Panel to view the SQL and press the Check SQL button I get the following message:
Parsing Result
[IBM][CLI Driver][DB2] SQL0501N The cursor specified in a FETCH or CLOSE statement is not open. SQLSTATE=24501
I have not worked with DB2 very much in the past and I am not familiar with what is causing this. Please provide me with some insight.
I too experience similar problems quite frequently, working in a DB2/400 environment. This problem only occurs when BO variables are used in the query, and could therefore be explained by the fact that any SQL statement ought to be prepared properly in order to run without problems. To my understanding, parsing an SQL statement does not as much prepare the statement, but only checks its syntax. Doing this, DB2 has to interprete the ‘unprepared’ BO variables, which is simply asking for trouble…
What I find (found) even more frustrating, is that whenever such a problem occurred, I couldn’t even close the SQL view anymore due to the error being displayed whilst hitting OK - i.e., even without clicking the Check SQL button! The only thing left to do in such a situation is to hit Cancel, thus losing any changes that were made to the statement.
Although I haven’t had a chance to test this, it seems that it has been fixed in version 4.1.3.