Find the status of the execution for stored procedure/SQL query using Perl

rohanan has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I am using the WIN32::OLE method to connect to a MS SQL database using perl and wanted to add some exceptional handling to my script especially when stored procedures fail to run. Currently I use a connection- my $Conn = Win32::OLE->new("ADODB.Connection");

Recordset(GetDataRS)-

$RS   = Win32::OLE->new("ADODB.Recordset");
$RS->Open($sql, $Conn, 1, 1);
return $RS
[download]

Running a query without a recordset(RunDBCmd)

$RS   = Win32::OLE->new("ADODB.Recordset");
$RS->Open($sql, $Conn, 1, 1);
[download]

How can I expect errors when I execute bad commands like - $SQLStr = "TRUNCATEsasdsa TABLE $database.dbo.$Tblname"; or $SQLStr = "EXEC <Storedprocedure with errors in it> "; thank you. -Ron

Comment on Find the status of the execution for stored procedure/SQL query using Perl Select or Download Code

Replies are listed 'Best First'.
Re: Find the status of the execution for stored procedure/SQL query using Perl by Anonymous Monk on Jan 27, 2012 at 21:17 UTC
Surely the MSDN docs would tell you :) You can use the standard DBI with DBD::ADO - A DBI driver for Microsoft ADO (Active Data Objects)	[reply]
Re: Find the status of the execution for stored procedure/SQL query using Perl by chacham (Prior) on Jan 29, 2012 at 11:52 UTC
When executing a command, iiuc, the driver implicitly creates an anonymous block for the execution. If the command itself is bad, the block will not compile and call itself will fail putting an error in the driver's error variable. If the code CALLs a stored PROCEDURE, and the error happens within it, as long as you are not trapping errors in the SP itself, the SP will fail and will pass the EXCEPTION to the anonymous block where it is (trapped by the driver and) put into the driver's error variable. If you trap EXCEPTIONs in the SP, your own code will do what you told it to, so unless you re-RAISE the EXCEPTION (making the trapping of it pretty useless to begin with) you won't get it. A simple statement like TRUNCATE is best implemented with host variables. It is more secure (no chance of SQL injection), and once put right, can not have syntactical errors.	[reply]