Skip to Content.
Sympa Menu

freetds - Re: [freetds] unhelpful error messages

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: christos AT zoulas.com (Christos Zoulas)
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] unhelpful error messages
  • Date: Wed, 9 Nov 2011 21:54:28 -0500

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





Archive powered by MHonArc 2.6.24.

Top of Page