Re: unhelpful error messages

Hi Christos, 

>     Msg 20009, Level 9, State -1, Server OpenClient, Line -1
>     Unable to connect: Adaptive Server is unavailable or does not
> exist There was a problem connecting to the server
> 
> is not very helpful. Was the server down? Did name resolution fail?

The OS error and result of strerror(3) are passed as the last two
arguments to the db-lib error handler.  What gets printed is up to the
application.  

I see they weren't being printed by bsqldb.  For shame!  I don't know
why they went missing.  I just added them.  

Distinguishing between different kinds of errors is something I've
worked to make clearer.  In the current version, connection
failures are routed to the error handler with distinct message
numbers, insofar as possible:

$ for S in nonesuch cherry thistle; do echo $S: && bsqldb -S $S; done

nonesuch:
bsqldb: Msg 20013, Level 2
Unknown host machine name

cherry:
bsqldb: Msg 20009, Level 9 (OS error 61: Connection refused)
Unable to connect: Adaptive Server is unavailable or does not exist

thistle:
bsqldb: Msg 20009, Level 9 (OS error 60: Connection timed out)
Unable to connect: Adaptive Server is unavailable or does not exist

Login errors arrive on the message handler:

$ bsqldb -S barley -U notme -P nopwd
Msg 18456, Level 14, State 1
Server '[barley]',  # <== local name
        Login failed for user 'notme'.
bsqldb: error: severity 14 > 10, exiting

$ bsqldb -S barley -U$U -P$P <<< 'select 1/0'
-----------
       NULL
Msg 3607, Level 0, State 0
Server 'TITAN', Line 1  # <== name reported by the server
        Division by zero occurred.
1 rows affected

The message you quote seems to be from the bsqldb *message*
handler.  In that case, there's no OS error because it's a message from
the server.  

> What was the name of the server? 

IIRC login rejections don't include the server name.  The 0.91 release
substitutes the local name (in a style I hope offers a clue that it's
not @@servername) when calling the message handler.  Previous releases
couldn't print the name because the actual parameter was a NULL.  

I am aware of two remaining problems in this vicinity:

1.  If 
	the servername resolves to an IP address, and 
    	freetds.conf says to use an instance name, and
	the server is not reachable (for any reason)
    then
 	the connection fails with *no* message because no 
	connection attempt is made, because port 0 
	is "obviously" wrong.  

2.  When making Kerboros connections, failures return a vague "unable
to connect" message regardless of the actual problem.  It's not
something I've had time to work on at work, and not something I'm set
up to work on at home.  

--jkl