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”.
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
MS SQL Server help also mentions that you have to call SQLError right after statement is executed.
PRINT '...begin' select * from foo.bar.mytable
In: hstmt = 0x00991FB8, szSqlStr = "", cbSqlStr = -3
stmt: szSqlState = "01000", *pfNativeError = 0, *pcbErrorMsg = 55,
+*ColumnNumber = -1, *RowNumber = 1
MessageText = "[Microsoft][ODBC SQL Server Driver][SQL Server]...b
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.
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.