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: Michael Peppler <mpeppler at MBAY dot NET>
Subject: RE: Problems understanding error handling
Date: Jul 22 1998 2:53PM

Phil Johnson writes:
 > 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?

There may be other reasons why you can't connect, like invalid
password, or failure at some other level.

However, to test for your specific errors the error handler is the
right place to do it.

I would run sample scripts with the NetGateway down and specifying an
incorrect server name and see what errors (both the error number and
the error string) you get in the error handler. Then you can code the
error handler (and the rest of your app) to do the right thing when
the errors occur.

Michael

 > 
 > 
 > 
 > > -----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
 > 
 > 

-- 
Michael Peppler         -||-  Data Migrations Inc.
mpeppler@mbay.net       -||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com