FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

dmarrer AT bci.cl wrote:
> > dmarrer AT bci.cl wrote:
> > > 
> > > I installed freetds on HPUX. I configured freetds.conf file but when
> > > I try  tsql, I receive an error. In the freetds.log file I see the
> > > following:
> > > 
> > > tdserror: client library returned TDS_INT_CANCEL(2)
> > > 
> > > With fisql, I can connect properly.
> > 
> > Please post a TDSDUMP log of the failed session.  Something is amiss. 
>
> Here is the TDSDUMP with tsql:
> 
> log.c:190:Starting log file for FreeTDS 0.82
>         on 2009-06-02 12:33:38 with debug flags 0x4fff.
> iconv.c:78:Using trivial iconv
...
> iconv.c:363:iconv to convert client-side data to the "roman8" character 
> set
> iconv.c:477:tds_iconv_info_init: use memcpy to convert
> "ROMAN8"->"UCS-2LE" net.c:210:Connecting to 192.168.1.3 port 1433 (TDS
> version 8.0) net.c:264:tds_open_socket: connect(2) returned "Operation
> now in progress" net.c:303:tds_open_socket() succeeded
> util.c:162:Changed query state from DEAD to IDLE
> login.c:735:quietly sending TDS 7+ login packet
> token.c:312:tds_process_login_tokens()
> util.c:334:tdserror(800000010000c540, 80000001000117c8, 20017, 0)
> util.c:368:tdserror: client library returned TDS_INT_CANCEL(2)
> util.c:389:tdserror: returning TDS_INT_CANCEL(2)

The server dropped the connection.  I suspect the login packet is invalid,
because:

1.  the server normally responds to malformed login packets by dropping
the connection, and

2.  'memcpy to convert "ROMAN8"->"UCS-2LE"' isn't right.  

But compare fisql: it doesn't think "ROMAN8" is the client character set;
it finds ISO-8859-1, which is fine ... and works.  

Maybe what's happening here is that tsql gets your client character set
wrong, and then the trivial built-in iconv doesn't recognize the name. 
The unknown-name default behavior is to do no conversion, which
*definitely* won't work for conversion to UCS-2, a 16-bit Unicode
encoding.  

Two bugs:

1.  tsql gets the client charset wrong.  Fortunately fisql gets it right,
so it's just a matter of comparing what they do.  

2.  tds_iconv_info_init() should assume the unknown client character set
is an ASCII derivative and treat it like ISO 8859-1 or UTF-8.  To assume
it's two-byte Unicode is to ask for trouble.  

> And this is the TDSDUMP with fisql
> 
> log.c:190:Starting log file for FreeTDS 0.82
>         on 2009-06-02 12:34:43 with debug flags 0x4fff.
> iconv.c:78:Using trivial iconv
...
> iconv.c:363:iconv to convert client-side data to the "ISO-8859-1" 
> character set
> iconv.c:516:tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
> iconv.c:516:tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"

That's good.  

> net.c:210:Connecting to 161.131.141.197 port 1433 (TDS version 8.0)
> net.c:264:tds_open_socket: connect(2) returned "Operation now in
> progress" net.c:303:tds_open_socket() succeeded
> util.c:162:Changed query state from DEAD to IDLE
> login.c:735:quietly sending TDS 7+ login packet
> token.c:312:tds_process_login_tokens()
...
> net.c:671:Received packet
> 0000 e3 1d 00 01 07 4d 00 45-00 54 00 41 00 34 00 51 |.....M.E .T.A.4.Q|
> 0010 00 41 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.A..m.a. s.t.e.r.|
> 0020 ab 72 00 45 16 00 00 02-00 26 00 43 00 68 00 61 |.r.E.... .&.C.h.a|
> 0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t|
> 0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o|
> 0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o|
> 0060 00 20 00 27 00 4d 00 45-00 54 00 41 00 34 00 51 |. .'.M.E .T.A.4.Q|
> 0070 00 41 00 27 00 2e 00 0d-53 00 52 00 56 00 2d 00 |.A.'.... S.R.V.-.|
> 0080 57 00 49 00 4e 00 50 00-45 00 50 00 44 00 45 00 |W.I.N.D. O.W.S.X.|

etc.  All good.  

OTOH, the two logs connections to different servers.  Maybe 192.168.1.3
port 1433 isn't really a SQL Server, or doesn't accept TDS 8.0 logins.  

HTH.  

--jkl