MS SQL Server help also mentions that you have to call SQLError right after statement is executed.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.
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 reply to Re^3: DBI Invalid Cursor State when PRINT statements are embedded in SQL
by terra incognita
in thread DBI Invalid Cursor State when PRINT statements are embedded in SQL
by JamesNC
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |