Front page | perl.dbi.users |
Postings from March 2008
Alexander Foken wrote: > 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. In SQL Server there is a print statement that may be used in procedures - see the t/20SQLServer test. >> 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. That is no longer true Alexander: MARS. Multiple Active Result Sets (MARS), enables your applications to have more than one pending request per connection, and, in particular to have more than one default result set open per connection. The MARS feature removes the restriction present in earlier versions of SQL Server in which an open default result set blocks the driver from sending requests to the server until the entire result set is consumed. > 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. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.comThread Previous | Thread Next