Прежде всего (в случае, если это важно) я использую Perl ActiveState (v5.8.7, построенный для многопоточности MSWin32-x86).
Я только что вышел из трехчасового сеанса отладки, пытаясь найти источник ошибки. Я обнаружил, что ошибки просто не было, но по какой-то причине объект соединения ADO увеличивался на Errors.Count
с каждым напечатанным сообщением в выводе моей хранимой процедуры.
Рассмотрим следующий код Transact SQL:
CREATE PROCEDURE dbo.My_Sample() AS
BEGIN TRAN my_tran
-- Does something useful
if @@error <> 0 BEGIN
ROLLBACK TRAN my_tran
RAISERROR( 'SP My_Sample failed', 16, 1)
END ELSE BEGIN
COMMIT TRAN my_tran
PRINT 'SP My_Sample succeeded'
END
Теперь представьте, что Perl более или менее похож на:
sub execute_SQL {
# $conn is an already opened ADO connection object
# pointing to my SQL Server
# $sql is the T-SQL statement to be executed
my($conn, $sql) = @_;
$conn->Execute($sql);
my $error_collection = $conn->Errors();
my $ecount = $error_collection->Count;
if ($ecount == 0 ) { return 0; }
print "\n" . $ecount . " errors found\n";
print "Executed SQL Code:\n$sql\n\n";
print "Errors while executing:\n";
foreach my $error (in $error_collection){
print "Error: [" . $error->{Number} . "] " . $error->{Description} . "\n";
}
return 1;
}
Где-то еще, в основном коде Perl, я вызываю вышеприведенную подпрограмму как:
execute_SQL( $conn, 'EXEC dbo.My_Sample' );
В конце концов я понял, что каждый оператор PRINT вызывает добавление новой псевдо-ошибки в коллекцию ошибок ADO. Быстрое исправление, которое я реализовал, состояло в том, чтобы превратить PRINT в SP в SELECT, чтобы обойти это.
Я хотел бы задать следующие вопросы:
- Это нормальное поведение?
- Есть ли способ избежать / обойти это?