http://www.perlmonks.org?node_id=400265


in reply to DBI Invalid Cursor State when PRINT statements are embedded in SQL

Don't think it is a problem with DBI, first of all DBI does nothing with your SQL statement.

And this is not a standard SQL statement, if you say this is fine with Sybase, then it is a Sybase extention. And it more like sort of debug method Sybase added (not a core function to the database manipulation or definition).

I would think it is way too normal for other databases not to recognize it.

  • Comment on Re: DBI Invalid Cursor State when PRINT statements are embedded in SQL

Replies are listed 'Best First'.
Re^2: DBI Invalid Cursor State when PRINT statements are embedded in SQL
by JamesNC (Chaplain) on Oct 18, 2004 at 18:53 UTC
    I agree.. I don't use this syntax, it is in a lot of store procs another guy wrote that I am trying to run from Perl.

    A DBA sent me this regarding MSSQL PRINT:
    The PRINT statement takes either one character or a Unicode string expression as a parameter. It returns the string as a message to the application. The message is returned as an informational error in ADO, OLE DB, and ODBC applications. SQLSTATE is set to 01000, the native error is set to 0, and the error message string is set to the character string specified in the PRINT statement. The string is returned to the message handler call-back function in DB-Library applications.

    How can I trap this error and continue? Would this be better as a new question at this point?
    James NC
      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.
      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.

        This was helpful... but any idea how can I capture both the SQL_SUCCESS_WITH_INFO __AND__ the results of the select? I see $dbh->errstr has MicrosoftODBC SQL Server DriverSQL Server...begin(SQL-01000) when the PRINT statement is run all alone, but get the cursor error when it is run with the select... arrgh...