An OpenESQL SQL CLR or DBMS vendor-specific stored procedure can:
To call a stored procedure that returns no result sets, use the CALL embedded SQL statement. For complete details on using this statement, see the CALL topic.
If a stored procedure returns one or more result sets, you must first declare it using the DECLARE CURSOR statement. For example:
EXEC SQL DECLARE cursorName CURSOR FOR storedProcedureCallStatement END-EXEC
You then call the stored procedure just as you would any other type of cursor using the OPEN statement to open the cursor, followed by the FETCH statement to fetch result set rows.
EXEC SQL GET NEXT RESULT SET FOR cursorName END-EXEC
If your GET NEXT RESULT SET statement returns an SQLCODE of 0, another result set is available, and you can issue another GET NEXT RESULT SET to retrieve it. However, if GET NEXT RESULT SET returns an SQLCODE of 100, no additional result sets are available.
Where :hvar is an integer host variable containing a count of the number of rows to be passed.
You return multiple result sets to a calling program by declaring one or more cursors in a stored procedure, and defining each declared cursor to return multiple result sets by including multiple SELECT statements in its definition.
EXEC SQL DECLARE C1 CURSOR FOR SELECT CUSTID FROM COMPANY; SELECT CUSTNAME FROM COMPANY; END-EXEC EXEC SQL OPEN C1 END-EXEC EXEC SQL DECLARE C2 CURSOR FOR SELECT COMPNAME FROM COMPANY; END-EXEC EXEC SQL OPEN C2 END-EXEC
In this example, we have two cursors, C1 and C2, with C1 returning two result sets, and C2 returning one result set. Therefore, these cursors return a total of three result sets to the calling application.
EXEC SQL CLOSE C1 WITH RETURN TO CALLER END-EXEC EXEC SQL CLOSE C2 WITH RETURN TO CALLER END-EXEC
Once the cursors are closed, the result sets associated with them become available to the calling application.
SQL CLR stored procedures that return result sets interact differently with their caller than do other types of stored procedures. For example, with z/OS DB2, a called COBOL stored procedure executes all its code, and then returns control completely to the caller. This is not the case with SQL CLR COBOL stored procedures. Control is returned to the caller after an EXEC SQL CLOSE cursor with RETURN TO CALLER is executed. After the caller consumes the corresponding result set (that is, it FETCHes until SQLCODE=100), control is then returned back to the SQL CLR stored procedure, which can then execute additional code. Therefore, in the case of a SQL CLR stored procedure, the stored procedure code itself is essentially placed in a wait state after executing the CLOSE cursor statement.
To get around this, we suggest that if possible, place all CLOSE with RETURN statements at the end of your stored procedure code rather than dispersing them throughout the stored procedure. This minimizes the number of interactions created by a SQL CLR stored procedure call, and basically eliminates the side effects that a high volume of interactions can create.
Keep in mind that with SQL CLR stored procedures, all result sets must be consumed first by the caller before output parameter values are available.