Chapter 3. Install FreeTDS

Table of Contents

The local environment
Choosing a TDS protocol version
Choosing protocol version since FreeTDS 1.1
Choosing protocol version before FreeTDS 1.1
Regarding obsolete versions
servername Lookup
The freetds.conf file
What it does
Where it goes
What it looks like
The locales.conf file
What it does
Where it goes
What it looks like
Environment variables
What they're for
Setting environment variables
Checking your work
Port/instance override syntax
Confirm the installation
Unit Tests

If you install it they will stay?

[Note]Confusing terminology

Configuring and installing don't have absolute, context-free definitions. In some circles, we install a product and then configure it. In the GNU world, we configure the package (generate the Makefiles), then we make install the package. In the case of a library package such as FreeTDS To install the package is to copy the files the application developer will use to their canonical locations: header files to include, libraries to the lib, documentation and man pages share. Install targets were specified during the build process as arguments to configure, covered in the last chapter.

For lack of a better term, this chapter describes installing the product. Put more specifically, once we're done with the package manager, we still have to tell FreeTDS about your database servers, and we still have to tell your client programs about FreeTDS.

The local environment

After FreeTDS has been built and installed, it still doesn't know where your servers are or what particular version of Sybase or Microsoft software each one is using.

The purpose of this section is to explain how to describe your servernames to FreeTDS. FreeTDS looks up your server's attributes in freetds.conf. Some of the attributes can be overridden by environment variables.

One of the more important (and arcane) settings is the TDS protocol version, described next.