PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: "Johnson, Phil" <Phil dot Johnson at fmr dot com>
Subject: RE: Problems understanding error handling
Date: Jul 20 1998 1:31PM

So if I wanted a finer granularity of detail I'd mess around with the
error_handler?

For instance, if the SybaseNetGateway is down (Unable to connect: SQL Server
is unavailable or does not exist.) I want to start the process so I can
connect.  If the server name is not found in the interfaces file, then I
want to exit.

Is messing around with the error_handler appropriate for this, or would it
be more prudent just to check the interfaces file from within perl and if it
doesn't exist, then inform the user and exit thus bypassing the sql()
routine altogether?

I'm assuming that there is only two kinds of connect failures:

1.  The process is down.
2.  The server name is not in the interfaces file.

Is this logic correct?



> -----Original Message-----
> From:	Michael Peppler [SMTP:mpeppler@mbay.net]
> Sent:	Friday, July 17, 1998 6:13 PM
> To:	SybPerl Discussion List
> Subject:	Problems understanding error handling
> 
> Johnson, Phil writes:
>  > I've been having some trouble understanding the whole error message
> handling
>  > spiel.
>  > 
>  > For the longest time, I've just been putting
> dbmsghandle("message_handler")
>  > at the top of my perl scripts and it has served me well.
>  > 
>  > Now, I need to actually trap an error (namely: Sybase error: Unable to
>  > connect: SQL Server is unavailable or does not exist.).  If I can't
> connect,
>  > then I must start up the Sybase NetGateway process via a system call.
>  > 
>  > Here is how I connect to a Sybase NetGateway:
>  > 
>  > $d = new Sybase::DBlib 'blar', 'bload', 'DCAT_DAL1_G_SYG';
>  > $ref = $d->sql("exec sgw_status clients");
>  > 
>  > for $line (@$ref) {
>  > 	do_stuff;
>  > }
>  > 
>  > So how do I trap the error that is generated by the $d = new
> Sybase::DBlib
>  > call?
> 
> What happens after a server error is detected depends on what is
> returned from the error_handler. For *server* errors the message
> handler is called first, and then the error handler. For *client*
> errors (typically the 'can't connect' error is a client error) only
> the error_handler is called. The important thing is to return
> INT_CANCEL from the error handler, and then to test the return value
> from new Sybase::DBlib to see if the dbopen() succeeded.
> 
> Something like:
> 
> #!/usr/local/bin/perl
> 
> use Sybase::DBlib;
> require 'sybutil.pl';
> 
> $dbh = new Sybase::DBlib user, pwd, server;
> if(!$dbh) {
> 	warn "connect failed!\n";
> }
> 
> produces:
> 
> Sybase error: Unable to connect: SQL Server is unavailable or does not
> exist.
> connect failed!
> 
> when the SQL server is not running.
> 
> Michael
> -- 
> Michael Peppler         -||-  Data Migrations Inc.
> mpeppler@datamig.com    -||-  http://www.mbay.net/~mpeppler
> Int. Sybase User Group  -||-  http://www.isug.com