Skip to Content.
Sympa Menu

freetds - Re: Odd program behavior

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Odd program behavior
  • Date: Sat, 29 Jan 2000 10:00:42 -0500 (EST)


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
> >
> >
> >





Archive powered by MHonArc 2.6.24.

Top of Page