Ramakrishna Raju wrote:
Alexander,
t-SQL has a print command and lot of stored procs have print
statements in the code to indicate progress of execution or whatever.
I need to capture it and print that to my log.
In the error handling department, if there is duplicate key
error on a insert or a table is missing, then that error gets printed to
the console thru the perl script, but it's getting printed thru some
low-level driver and not by the user statement. I need to grab that
error situation and send out an email or something. How do I do that?
I will do some reading and try to put something together and
then we can compare notes.
Start your reading with the PrintError, RaiseError and HandleError
attributes in DBI. Of course, once you've looked at the 20SqlServer
example in DBD::ODBC you will see it uses HandleError.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
-----Original Message-----
From: Alexander Foken [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 2:41 PM
To: Ramakrishna Raju
Cc: dbi-users@perl.org
Subject: Re: perl DBI on windows 64
On 13.03.2008 19:49, Ramakrishna Raju wrote:
And now, I am looking for a web link or a short snippet that
does robust error handling of SQL errors.
Use the RaiseError DBI attribute, preferably during connect().
And how to process the output
of sql print statements.
SQL does not print, it has no print statements (at least there not
portable ones). You may want to print what $sth->fetchXXX returns. For
debugging, you may want to use Data::Dumper.
I've done Sybase db-lib programming more than
15 years back and I realize that are 2 channels back to the client, a
message handler and an error handler. How is it done in perl odbc?
You don't care about that. DBI will handle that for you. Sybase db-lib
is one level below DBI. Look at the DBI documentation
<http://search.cpan.org/perldoc?DBI>. There is also an O'Reily book
about the DBI <http://www.oreilly.com/catalog/perldbi/>, it even has an
example collection page online at
<http://examples.oreilly.com/perldbi/>.
There is one annoyance with SQL server: You can't have more than one
"active" statement, i.e. a statement that is executing but not yet
finished, per connection. This is a limitation of the SQL server
protocol, not a DBI limitation. Other databases, like Oracle and the
free PostgreSQL, can handle at least a sufficiently large number of
parallel active statements. For the MS SQL Server, you have to use
several distinct connections if you need parallel active statements.
Personally, I would never start a project on MS SQL Server if I can use
Oracle or PostgreSQL. Not just because of that limitation, but also
because of some other annoyances, like the trigger implementation and
the regular deadlocks of MS SQL Server.
Alexander
