Re: Only TDSVER=4.2 works when connecting to MS SQL 2005

"Michael Gurfinkel [TSS]" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of James 
> K. Lowden
> Sent: Tuesday, September 06, 2011 6:23 PM
> To: [email protected]
> Subject: Re: [freetds] Only TDSVER=4.2 works when connecting 
> to MS SQL 2005
> 
> On Tue, 6 Sep 2011 13:46:29 -0700
> "Michael Gurfinkel [TSS]" <[email protected]> wrote:
> 
> > > > 14:36:28.595890 3933 (login.c:1057):detected flag 2
> > > > 14:36:28.595903 3933 (login.c:782):quietly sending TDS 7+ login 
> > > > packet
> > > ...
> > > > 14:36:28.596526 3933 (dblib.c:7929):dbperror(804f988, 20017, 0)
> > > > 14:36:28.596541 3933 (dblib.c:7981):20017: "Unexpected EOF from 
> > > > the server"
> > > 
> > > The server is rejecting your login, but not for a bad 
> > > username/password (else you'd see a message).  Is there 
> some sort of 
> > > encryption or Kerberos login being used, or supposed to be?
> > 
> > I am not aware of any encryption or Kerberos login, but I 
> don't know 
> > how to validate it. All I know this is 2005 SQL Server with 
> > authentication set to mixed (Windows and SQL Server) mode.
> 
> This for sure: FreeTDS logs in to Microsoft servers for 
> thousands of users every day.  What you're seeing is 
> therefore attributable to the server's setup.  
> 
> Perhaps FreeTDS should be able to handle that setup, but 
> behaves in a way unacceptable to the server. Unfortunately, 
> the server's response in such cases is unhelpful: it simply 
> hangs up.  That leaves you with some investigation to do.  
> 
> You could try other servers, even install the Express 
> product, and then triangulate settings with your DBA.  Or you 
> could recompile FreeTDS to log the login packets, which would 
> show exactly what happened, but not necessarily in the most 
> comprehensible form.  
> 
> > What would be my limitations if I will use 4.2?  
> 
> You don't want to do that.  You lose BCP and every datatype 
> added in the last ten years, and you'd probably find other 
> mysterious "features"
> because you'd be running the only 4.2 connection since the 
> Mets last won the World Series.  
> 
> --jkl
> 

Thanks for your replies.
I has been working on old SCO OpenServer box, so I decided to verify my
issue by running FreeTDS on a more recent Linux system. 

On the new box I am able to connect to the with 7.1; when I specify 7.2 I am
getting downgraded, see below:

util.c:331:tdserror(0x804f020, 0x804f960, 100, 0)
dblib.c:7929:dbperror(0x804f1a0, 100, 0)
dblib.c:7981:100: "TDS version downgraded to 7.1!"
dblib.c:5780:dbgetuserdata(0x804f1a0)
dblib.c:4880:dbdead(0x804f1a0) [dead]

I took err_handler from example and patched it to say that if(dberr == 100)
to behave as anticipated error and I am able to select / update / insert.
Would you please let me know if I should try to dig further and see why 7.2
is not happy with my 2005 db? Please clarify.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.