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/
