Skip to Content.
Sympa Menu

freetds - Re: tds 7.0 versus MSSQL 2000

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: tds 7.0 versus MSSQL 2000
  • Date: Wed, 5 Dec 2001 07:37:16 -0500 (EST)


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





Archive powered by MHonArc 2.6.24.

Top of Page