FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

Hi Ian,

On Tue, 28 Mar 2000, Ian Charnas wrote:

> Sorry for including the entire original message, just in case you forgot my
> plea for help.  I got it to work, here's how I did it, and why I'm a lamer.
>
Don't be so hard on yourself...I often find the stupid mistakes are the
hardest to catch because you tend to overlook them so easily (again and
again and again)  :-)
 
> I downloaded freetds 0.50 again, untarred it and such, went into the
> src/tds/ directory, edited token.c, went into the tds_process_msg(...)
> function, and un-commented the following line, which is sorta at the end of
> tds_process_msg(...):
> 
> if(tds->msg_info->msg_number)
>      fprintf(stderr, "Msg %d, Level %d, State %d, Server %s, Line %d\n%s\n",
>      tds->msg_info->msg_number,
>      tds->msg_info->msg_level,
>      tds->msg_info->msg_state,
>      tds->msg_info->server,
>      tds->msg_info->line_number,
>      tds->msg_info->message);
> 
> At which point I compiled freetds, compiled my test program, and learned
> very quickly that I (and here's where I'm a lamer) had inadvertantly
> switched tds_set_user(...) and tds_set_passwd(...) in my test program, which
> when properly fixed allowed me to connect to our production server.
> 
> I just wanted to say thank you for your help and paitence as I try to be
> more intelligent, and if anyone's getting odd responses from their SQL
> server, they might want to try uncommenting that line as I did.  Actually,
> it'd be cool if tds_process_msg(...) checked to see if an environment
> variable, say TDSLOGMSG was set or not set, and if it was set, and TDSDUMP
> was also set, then tds_process_msg(...) would add all messages to the
> TDSDUMP file in the same format as that line I uncommented.  Just a
> suggestion.
> 
Great suggestion. Actually it should just dump if TDSDUMP is set at all.
Certainly would have helped here.

> Thanks again Brian and Bob.  I'll let the mailing list know when my apache
> module (mod_auth_tds) is done.
>
I'm very interested in this, since I may have a need for something similar
at work.
 
> Ian Charnas.
> 
> 
> ----- Original Message -----
> From: "Brian Bruns" <camber AT umcc.ais.org>
> To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
> Sent: Wednesday, January 26, 2000 7:50 PM
> Subject: [freetds] Re: Odd program behavior
> 
> 
> >
> >
> > On Wed, 26 Jan 2000, Ian Charnas wrote:
> >
> > > Hello, I'm a college programmer writing some apache authentication
> modules,
> > > and I'm currently working on mod_auth_tds which will authenticate users
> via
> > > a Sybase or MS SQL database server.  I'm currently planning on using
> > > freetds as my C interface into the database servers.
> > >
> > > I wish I could have figured this out myself, but I can't.  I read the
> FAQ
> > > over and over, I read all the archived messages from the mailing list,
> and
> > > I looked through all the pertinant source code, but I still can't figure
> > > out how to fix this problem:
> > >
> > > I compiled the code found at the bottom of the message, which is simply
> a
> > > test to see if the program can login correctly to the SQL server, and it
> > > connects to myserver1 correctly.  myserver1 is a development server
> running
> > > NT 4.0 server and SQL 7.0.
> > >
> > > The problem is when I try to connect to the production server (myserver2
> > > let's call it) running the same operating system and the same SQL Server
> > > (same versions of course).  That continually fails on login.  I'm sure
> the
> > > username/password is correct, I'm fairly sure the interfaces file is
> > > correct in syntax, and I configured FreeTDS --with-tdsver=4.2 as I
> should
> > > have.
> > >
> > > The odd thing is I can however, connect to both myserver1 and myserver2
> if
> > > I write the code in perl and use DBD::Sybase and the DBI scheme, which
> lets
> > > me know it's not a network problem, my username/password is correct, and
> so
> > > on.
> > >
> > Interesting one, I was about to suggest it might be that you had only
> > domain logins to the second server, but this blows that theory out of the
> > water. Are you using the same service pack on both servers?
> >
> > > So, I set the TDSDUMP environment variable and the following is a
> partial
> > > printout of the error according to the log file...(I neglected to
> include
> > > the printout of what packets were sent, because they contain my
> > > username/password)
> > > /****************************/
> > > 2000-01-26 01:13:10 inside tds_process_login_tokens()
> > > 2000-01-26 01:13:11 inside tds_process_default_tokens() marker is aa
> > > 2000-01-26 01:13:11 inside tds_process_default_tokens() marker is fd
> > > 2000-01-26 01:13:11 leaving tds_process_login_tokens() returning 0
> > > /****************************/
> > >
> > > Anyone have any idea as to what I can try to get this to work?
> > >
> > This shows that you are getting a valid return from the SQL Server, but
> > alas not a login acknowledgement.
> >
> > I tried your script and was able to connect against Sybase...have not been
> > able to try MS SQL yet. (hopefully tommorow).
> >
> > So, here is what to do...see that marker is aa message up there? that's
> > your error that the database is returning. you need to print the text of
> > that out.  Way number one, install a message handler...you can look in
> > dblib or ctlib for specifics...(I should create a sample showing how to do
> > this someday)...Way number two (the easy way) run this through the
> > debugger, set a breakpoint in  tds_process_msg() and print the relevent
> > variables.
> >
> > Hope this helps, and send me a link to your program when its done!
> >
> >
> > Brian
> >
> >
> >