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.
Thanks,
Ramakrishna Raju ( "Raju" )
[EMAIL PROTECTED]
-----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
--
Alexander Foken
mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
DISCLAIMER: NOTICE REGARDING PRIVACY AND CONFIDENTIALITY
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this e-mail,
you are hereby notified that any dissemination, distribution or copying of this
e-mail, and any attachments thereto, is strictly prohibited. If you have
received this e-mail in error, please immediately notify me and permanently
delete the original and any copy of any e-mail and any printout thereof. E-mail
transmission cannot be guaranteed to be secure or error-free. The sender
therefore does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. TJM Proprietary
Trading, LLC ("TJMPT") may, at its discretion, monitor and review the content
of all e-mail communications. TJMPT is a registered joint back office broker
dealer with the Chicago Board of Options Exchange "CBOE". TJMPT's office is
located at 318 W. Adams Floor 9, Chicago, IL 60606. For more information about
TJMPT, please call us at (312)-432- 5100 or fax (312)-432-4498.
