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 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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: DBI Invalid Cursor State when PRINT statements are embedded in SQL
by JamesNC (Chaplain) on Oct 18, 2004 at 19:55 UTC | |
by 18th_bronzeman (Novice) on Sep 21, 2007 at 23:00 UTC |