FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Wed, 5 Dec 2001, Kaido Kärner wrote:

> re
> 
> tried to connect from linux box to MSSQL 2000 via freetds 0.53 / dblib
> with no success. 4.2 seems to be working.
> 
> tries using dblib/unitests/t0001.c
> 
> (note that makefiles in dblib/unitests/ did not make the tests, but that's
> ok - can build them manually)

make check will build them, but i agree, 'make' should as well.
 
> MSSQL version:
> 
> Microsoft SQL Server  2000 - 8.00.194 (Intel X86) 
>       Aug  6 2000 00:57:48 
>       Copyright (c) 1988-2000 Microsoft Corporation
>       Personal Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
> 
> after short debugging the following was found:
> 
> 1. 
> 
> in tds/login.c in function tds7_send_login() nobody checks whether
> config->host_name, config->host or config->password are not NULL - so
> segfault. added the following as a quick workaround:
> 
> if (!config->host_name) config->host_name=strdup(config->ip_addr);
> if (!config->host) config->host=strdup(config->ip_addr);
> if (!config->password) config->password=strdup("");
 
This is fixed in the CVS version (and 0.53pre3), specifically which 
pre-release are you running?
 
> 2.
> 
> next, the packet which was returned as indication of successful login, did
> not get parsed correctly. the problem seems to be in
> tds_process_env_chg(), which does not handle sizes correctly .. seems that
> (at least in case of my server) the blocks with marker=e3 have size in
> their next 2 bytes. that's read in tds_process_env_chg(), but not used.
> well, I made another quick hack to overcome this and remembered the
> tds->in_pos and size just read at the start of tds_process_env_chg() and
> set tds->in_pos = stored pos + stored size at the exit. this seemingly
> fixed that problem ..

I believe what you are seeing here is a bug that existed in....i think 
pre1 that some debugging code attempted to use TDS 8 to log in.  Verify by 
looking for '0x80' in tds7_send_login().  Again fixed in CVS. 

> 3.
> 
> 
> next, getting results back from the server seems not to work.
> 
> I have the following packet received:
> 
> Received packet @ 2001-12-05 13:41:34
> 0000  81 02 00 00 00 08 00 38 01 69 00 00 00 08 00 af   |.......8.i......|
> 0010  0a 00 25 04 d0 00 9c 01 73 00 a9 02 00 01 00 d1   |..%.....s.......|
> 0020  00 00 00 00 0a 00 72 6f 77 20 30 30 30 20 20 20   |......row 000   |
> 0030  d1 01 00 00 00 0a 00 72 6f 77 20 30 30 31 20 20   |.......row 001  |
> 0040  20 d1 02 00 00 00 0a 00 72 6f 77 20 30 30 32 20   | .......row 002 |
> 0050  20 20 d1 03 00 00 00 0a 00 72 6f 77 20 30 30 33   |  .......row 003|
> 0060  20 20 20 d1 04 00 00 00 0a 00 72 6f 77 20 30 30   |   .......row 00|
> 0070  34 20 20 20 fd 10 00 c1 00 05 00 00 00            |4   .........|
> 2001-12-05 13:41:54 inside dbresults()
> 2001-12-05 13:41:54 processing result tokens.  marker is  81 at pos=1
> 2001-12-05 13:41:54 processing result tokens.  marker is  30 at pos=5e
> 
> to those last two lines in the log I've added the position of the marker
> to see where it's stuck - and as it seems that position 5e in just inside
> the data - something went wrong ..
> 
> note that after the number of fields {02 00} there is 00 00 08 00, not 00
> 00 01 00 as the comment in code seems to think ..
> 
> if somebody will look at those issues and probably fix those I'm glad to
> investigate further ..

And yet again, trying to use TDS 8.0 (which will get you a log in but 
crash there after...we are actually pretty close to having it work). An 
update to 0.53pre3 or nightly snapshot should take care of it.

> regards,
> kaido
> 
> kaido@tradenet,ee
> 

Cheers,

Brian