Front page | perl.dbi.users |
Postings from March 2008
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:alexander@foken.de] > 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 > >Thread Previous | Thread Next