Skip to Content.
Sympa Menu

freetds - RE: [freetds] Issues with FreeTDS installation / Environment vari ables

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Issues with FreeTDS installation / Environment vari ables
  • Date: Tue, 17 Jun 2003 12:35:09 -0400

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: June 17, 2003 11:46 AM
>
> I will want to deploy freetds in a number of disparate
> environments. All are
> SUN/Solaris at the moment, but the target application hosts
> do not conform
> to any single standard in terms of filesystems, where third party or
> proprietary application software is installed etc. In other
> words, I may be
> required to install freetds into /opt ; /apps ; /usr/local ;
> yada yada...
...
> In order for freetds to find the freetds.conf file on the
> remote server, any
> application needs to set the FREETDSCONF variable to point to
> it's real location.
> Unfortunately no such mechanism exists, as far as I can tell,
> to override
> the location of the locales.conf file . which has caused me a
> couple of problems recently.

Hi Bill,

Modern FreeTDS configuration theory ;-) holds that locales.conf is toast,
headed for the attic, a mere shell of its former self, a hanger-on. In a
word: deprecated.

We've learned a lot about locales lately. We know how to ascertain the
charset from the OS, how to map the OS's name to our canonical one, how to
convert that to Sybase's name.

locales.conf had three purposes:

1. Set a default and per-locale date format.
2. Set the server natural language by locale.
3. Set the server charset by locale.

#3 is superseded in CVS. #2 is easy to implement in our new charsetname
framework. That leaves dates.

Encoding per-locale default date format strings is silly, we now know.
Better to query the OS with nl_langinfo(D_T_FMT) and friends. That leaves
the default date format, which could easily and should be moved to the
[global] section of freetds.conf. (That would let folks define per-server
formats, which is also a little silly but harmless.)

So.

IMO, the most straightforward fix is to move the default date format to
freetds.conf. Then you can operate without locales.conf. Enhancements
would be to handle #2, above, and to rip out all references to locales.conf
from the code and documentation.

For sake of those who might not know, FreeTDS 0.61 will operate without
locales.conf. The server language will be "us_english" and the charset
"iso_1". The date format will vary by library, reflecting the vendors'
defaults. It was that variability that led to locales.conf in the first
place.

Regards,

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.





  • RE: [freetds] Issues with FreeTDS installation / Environment vari ables, Lowden, James K, 06/17/2003

Archive powered by MHonArc 2.6.24.

Top of Page