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.

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.
[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.

I have never seen this syntax, and a quick look through the DBI book doesn't yield any likening to this syntax.

edit: popped open my sql server docs and found that it's a T-SQL function. My understanding has been that you can use T-SQL via ODBC, but I don't quite think you need to use it here. This may be one function that doesn't work within DBI::ODBC due to what state the cursor needs to be in for the T-SQL command to work.

Thanks for the help. The syntax is valid in Sybase too. And I just verified that Sybase doesn't complain if it is at the begining, or anywhere else but nothing gets printed. It must act like a "GO" in that it never sent to the interpreter ever, but MSSQL doesn't like it.

#!C:/perl/bin/perl -w
#DBI 1.45
#DBD::ODBC 1.11
use DBI;
$dbh =  DBI->connect("dbi:ODBC:tmpDB", 'username','password', 
    { PrintError => 1, RaiseError =>0, LongReadLen => 65536,
          odbc_async_exec => 1, odbc_err_handler => \&errSub }
);


$command = qq/
select 'start'
select name = 'dbi-user'
select 'end'
/;


$sth = $dbh->prepare($command);
    die $DBI::errstr unless $sth;

my $rc = $sth->execute(); 


do {


    my @row;
    while (@row = $sth->fetchrow_array()) {
          print join(",", @row), "\n";
    }

} while ($sth->{odbc_more_results});

$dbh->disconnect;

sub errSub {

     my ($state, $msg) = @_;
     # Strip out all of the driver ID stuff
     $msg =~ s/^(\[[\w\s]*\])+//;
     my $err_text .= $msg."\n";
     print "Err($state):",$err_text;

}
[download]