FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> lisa yang wrote:
> > Since We used XAMPP (http://www.apachefriends.org/en/) for 
> our Apach,
> > PHP, MySQL setting, which has FreeTDS installed and configured by
> > default. 
> 
> OK, then you really have to talk to them.  See below for the issue.  
> 

A low level way to discover compiled option is to do a

$ strings filetds.so | grep 'freetds.conf'

(strings is usually in binutils, a development package)

> > 1. How to make freeTDS use freetds.conf instead of bypassing it?
> 
> You're not "bypassing" freetds.conf when you're running 
> Apache.  FreeTDS
> is linked in -- i.e. part of -- the Apache executable.  
> What's happening
> is that FreeTDS is not finding freetds.conf because it's not where it
> should be, where "should" is defined by how it was configured 
> when it was
> built.  
> 
> Neither you nor I know what FreeTDS options were used at 
> build time.  If
> you find that out, you'll know where to put your freetds.conf.  Or, at
> least, you *can* know.  Right now, it's anybody's guess.  
> 
> > I don't know why there is no TDSDUMP log file (I have run $ export
> > TDSDUMP=/etc/freetds.log ) and why $ export
> > FREETDSCONF=/etc/freetds.conf doesn't work.
> 
> I think what you're missing is some basic knowledge about how 
> environment
> variables work.  Even though it's a little off-topic here, 
> I'll explain if
> you'll bear with me.   
> 
> When Apache starts, it's running under an account, just as 
> you're running
> under an account when you log in.  Whatever variables you set 
> affect your
> session and no one else's, include Apache's.  For those 
> variables to have
> any effect on FreeTDS, they have to be set in Apache's 
> session before it
> starts.  And the account that Apache is running under needs 
> write access
> to the file named in TDSDUMP/FREETDSCONF.  I point that out 
> because it's
> unlikely that the Apache account, 'httpd' or whatever it is, will have
> write access to /etc.  TDSDUMP=/tmp/freetds.log might be a 
> better choice. 
> 
> 
> You do give me a novel idea for a future feature, though!  If FreeTDS
> monitored the SQL, it could trap select statements to a 
> "magic" table. 
> Then if you issued a query like "select * from 
> FREETDSCONF_MAGICTABLE", it
> would return a result set of its configuration information.  
> That would be
> cool.  
> 
> (A less ambitious project would be to add the information you need to
> "tsql -C".)
> 
> But we don't have a magic table.  You'll have to ask the 
> XAMPP folks.  
> 

I don't like that much this magic table idea, for example cause if
connection fail you can't issue the query and also cause it require
query parsing...

In PHP script you can use putenv (see
http://it2.php.net/manual/en/function.putenv.php) to set variable
(before connection).

> > 2. If in my PHP code, 
> > mssql_connect ("domainName:1433", "sa", "XXXXX"); 
> > 
> > If successfully connected to MS SQL 2000 and successfully 
> selected the
> > tables I wanted, do I really need to care about freetds used
> > freetds.conf or not? 
> 
> Well, maybe, maybe not.  There are other options controlled by
> freetds.conf that you can't set that way.  And if your 
> server's name/port
> changes, it would be nice not to have that stuff burned into your
> application.  
> 
> HTH.
> 

tds version, client encoding and other options require freetds.conf and
are very useful.

freddy77