Martin, Thanks for the pointers. And please do an FAQ entry for ODBC on windows 64bit. That would be a tremendous help and save hours of frustration.
Ramakrishna Raju ( "Raju" ) [EMAIL PROTECTED] -----Original Message----- From: Martin Evans [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 4:07 AM To: dbi-users@perl.org Subject: Re: perl DBI on windows 64 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 > > 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.
