FreeTDS Development Group

[christos AT zoulas.com (Christos Zoulas)]

On Nov 9,  8:56pm, jklowden AT freetds.org ("James K. Lowden") wrote:
-- Subject: Re: [freetds] unhelpful error messages

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

I think tsql has the same problem. Perhaps we should check them all.

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

All that is excellent then.

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

The code is calling error_message() which is ok, but it is not passing
the message from what I can see to the error function later. It is probably
better to use the gssapi function to retrieve the error message rather
than the kerberos level ones like so:

        http://www.zoulas.com/junk/gss_strerror.c

I think that the only thing to do here is pass the string of the kerberos
error along.

Or am I missing something?

christos