Re^3: DBI Invalid Cursor State when PRINT statements are embedded in SQL

in reply to Re^2: DBI Invalid Cursor State when PRINT statements are embedded in SQL
in thread DBI Invalid Cursor State when PRINT statements are embedded in SQL

Your DBA is right. Here is the output from ODBC test. ODBC test seems to know that this is a partial success and returns the rowset as well the “error message”.

PRINT '...begin' select * from foo.bar.mytable
SQLExecDirect:
In:    hstmt = 0x00991FB8, szSqlStr = "", cbSqlStr = -3
Return:    SQL_SUCCESS_WITH_INFO=1
stmt:    szSqlState = "01000", *pfNativeError = 0, *pcbErrorMsg = 55, 
+*ColumnNumber = -1, *RowNumber = 1
    MessageText = "[Microsoft][ODBC SQL Server Driver][SQL Server]...b
+egin"

Get Data All:
    -1 rows affected by INSERT/UPDATE/DELETE or other statement.

"col1", "col2", "col3"
1, "row1", "row1"
2, "row2", "row2"
2 rows fetched from 3 columns.
[download]

MS SQL Server help also mentions that you have to call SQLError right after statement is executed.

The timing of calling SQLError is critical when output from PRINT or RAISERROR statements are included in a result set. The call to SQLError to retrieve the PRINT or RAISERROR output must be made immediately after the statement that receives SQL_ERROR or SQL_SUCCESS_WITH_INFO. This is straightforward when only a single SQL statement is executed, as in the examples above. In these cases, the call to SQLExecDirect or SQLExecute returns SQL_ERROR or SQL_SUCCESS_WITH_INFO and SQLError can then be called. It is less straightforward when coding loops to handle the output of a batch of SQL statements or when executing SQL Server stored procedures.

In Section Seekers of Perl Wisdom