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