FreeTDS Development Group

["Mike C." <mcbp223 AT yahoo.com>]

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org]On Behalf Of Steve Kirkendall
> Sent: Saturday, April 17, 2004 6:38 PM
> To: FreeTDS Development Group
> Subject: More on using FreeTDS on a server (was Re: [freetds] Server
> dumpscore...)
>
> Here's the latest on my efforts to use FreeTDS for server-side networking.
>
> First the bad news: Microsoft's ODBC driver for SQL Server still refuses
> to talk to my little server.  All I get is a generic "Protocol error in
> TDS stream".  I suspect I'm failing to send some critical token in the
> login response, but it's hard to be sure with an error message that vague.

Here are some observations on my tests with Microsoft's drivers (odbc and
oledb):

First, it sends TDS_PRELOGIN(0x12), to check if you're talking TDS7+; if you
just send done (#253), or the conforming response (don't know the
structure), it will send you a TDS7 login packet. If you send NACK - login
error, it will send you a TDS 4.2 login packet.
As long as you consume everything from the incoming socket, you can answer
done(#253) to each message flagged with last, and the TDS flow should go on,
without protocol error.
In the login response, you can force your own packet size independently from
what the driver asked, with an envchange.

I think a good example on talking to the MS drivers is procsrv, which they
made available with the late 'open data services', in 1996. That one could
help also if you want to implement the srv_* API's against FreeTDS.

Just checking, but I guess you're using a packet sniffer to compare what the
*real* thing speaks with what your implementation does.

> * I have a log, produced by FreeTDS, of the network traffic in my failed
>   attempts to access my little SQL server via Microsoft's ODBC driver.
>   Does anybody out there have a similar dump of a *successful* login?
>   Nothing fancy, just a TDS4.2 login such as the "test connection"
>   button in the ODBC Microsoft SQL Server Setup dialog.

The "test connection" in the ODBC setup will ask you some indecent questions
about the master database, better focus on Query Analyzer, which is more
forgiving, until you get the flow done.
Other high level applications such as the java iSQL Viewer will get puzzled
if you don't answer correctly to the internal driver queries, thus so far QA
seems to be the most enduring one.

Mike