Sophie: freetds-doc-0.91-8.mga5 x86

freetds-doc-0.91-8.mga5.x86_64.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML
><HEAD
><TITLE
>Preparing ODBC</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="FreeTDS User Guide"
HREF="index.htm"><LINK
REL="PREVIOUS"
TITLE="Confirm the installation"
HREF="confirminstall.htm"><LINK
REL="NEXT"
TITLE="Connection attributes"
HREF="odbcconnattr.htm"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="userguide.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=utf-8"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
><SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> User Guide: A Guide to Installing, Configuring, and Running <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="confirminstall.htm"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="odbcconnattr.htm"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="PREPODBC"
></A
>Chapter 4. Preparing ODBC</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
><A
HREF="prepodbc.htm#ODBCBACKGROUND"
>Background and Terminology</A
></DT
><DT
><A
HREF="odbcconnattr.htm"
>Connection attributes</A
></DT
><DT
><A
HREF="dsnless.htm"
>DSN-less configuration</A
></DT
><DT
><A
HREF="odbcinionly.htm"
>ODBC-only configuration</A
></DT
><DT
><A
HREF="odbcombo.htm"
>ODBC-combined configuration</A
></DT
><DT
><A
HREF="odbcdiagnose.htm"
>Troubleshooting ODBC connections</A
></DT
></DL
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="ODBCBACKGROUND"
>Background and Terminology</A
></H1
><P
>To connect to a database server, a library such as <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> needs some information about the connection.  By <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>server</I
></SPAN
>, which IP address and port is do you mean?  Which user is requesting the connection, and what authentication does he offer?  Every database library needs a way to capture and convey that information.</P
><P
>ODBC was conceived as a general interface definition, not tied to any particular database or access library.  For that reason, ODBC also needs to know which driver to use with a given server.</P
><P
>The original ODBC solution to this conundrum employed the <TT
CLASS="FILENAME"
>odbc.ini</TT
> file.  <TT
CLASS="FILENAME"
>odbc.ini</TT
> stored information about a server, known generically as a <I
CLASS="FIRSTTERM"
>Data Source Name</I
> (DSN).  ODBC applications connected to the server by calling the function <CODE
CLASS="FUNCTION"
>SQLConnect(DSN, UID, PWD)</CODE
>, where <TT
CLASS="REPLACEABLE"
><I
>DSN</I
></TT
> is the Data Source Name entry in <TT
CLASS="FILENAME"
>odbc.ini</TT
>, <TT
CLASS="REPLACEABLE"
><I
>UID</I
></TT
> is the username, and <TT
CLASS="REPLACEABLE"
><I
>PWD</I
></TT
> the password. Any and all information about the DSN was kept in <TT
CLASS="FILENAME"
>odbc.ini</TT
>.  And all was right with the world.</P
><P
>The ODBC 3.0 specification introduced a new function: <CODE
CLASS="FUNCTION"
>SQLDriverConnect</CODE
>.
			The connection attributes are provided as a single argument, a string of concatenated name-value pairs.  <CODE
CLASS="FUNCTION"
>SQLDriverConnect</CODE
> subsumed the functionality of <CODE
CLASS="FUNCTION"
>SQLConnect</CODE
>, in that the name-value pair string allowed the caller to pass &mdash;  in addition the the original <TT
CLASS="LITERAL"
>DSN</TT
>, <TT
CLASS="LITERAL"
>UID</TT
>, and <TT
CLASS="LITERAL"
>PWD</TT
> &mdash; any other parameters the driver could accept. Moreover, the application can specify which driver to use.  In effect, it became possible to specify the entire set of DSN properties as parameters to <CODE
CLASS="FUNCTION"
>SQLDriverConnect</CODE
>, obviating the need for <TT
CLASS="FILENAME"
>odbc.ini</TT
>.  This led to the use of the so-called <I
CLASS="FIRSTTERM"
>DSN-less</I
> configuration, a setup with no <TT
CLASS="FILENAME"
>odbc.ini</TT
>.</P
><P
>But <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> did not start out as an ODBC driver (remember <SPAN
CLASS="SYSTEMITEM"
>DB-Library</SPAN
> and <SPAN
CLASS="SYSTEMITEM"
>CT-Library</SPAN
>), and has always had its own way to store server properties: <TT
CLASS="FILENAME"
>freetds.conf</TT
>.  When Brian added the <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> ODBC driver, he began by supporting the old <CODE
CLASS="FUNCTION"
>SQLConnect</CODE
>, using <TT
CLASS="FILENAME"
>odbc.ini</TT
> to describe the DSN.  That choice complied with the expectations of the Driver Managers, and minimized the amount of duplicated information in the configuration files.  But it can be a little confusing, too, because <TT
CLASS="FILENAME"
>odbc.ini</TT
> in effect points to <TT
CLASS="FILENAME"
>freetds.conf</TT
>.  We call this configuration <I
CLASS="FIRSTTERM"
>ODBC-combined</I
>, because it supports all three <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> libraries.</P
><P
>As progress on the the <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> ODBC library progressed, the driver was made able to read the connection attributes directly from <TT
CLASS="FILENAME"
>odbc.ini</TT
>, rather than leaning on <TT
CLASS="FILENAME"
>freetds.conf</TT
>.  For installations that don't need <SPAN
CLASS="SYSTEMITEM"
>DB-Library</SPAN
> and <SPAN
CLASS="SYSTEMITEM"
>CT-Library</SPAN
>, this <I
CLASS="FIRSTTERM"
>ODBC-only</I
> setup is simpler.</P
><P
>More recently, <CODE
CLASS="FUNCTION"
>SQLDriverConnect</CODE
> was added to <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
>.  As described above, this function allows the application to specify connection attributes with reference to either, or neither, configuration file.  It's your choice.  In making that choice, keep the following terms clear in your mind:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><P
><B
>Important <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> ODBC terms</B
></P
><DL
><DT
><TT
CLASS="LITERAL"
>SERVERNAME</TT
></DT
><DD
><P
>specifies the <TT
CLASS="LITERAL"
>[<TT
CLASS="REPLACEABLE"
><I
>servername</I
></TT
>]</TT
> entry in <TT
CLASS="FILENAME"
>freetds.conf</TT
>.</P
></DD
><DT
><TT
CLASS="LITERAL"
>SERVER</TT
></DT
><DD
><P
>specifies the real server i.e., the TCP/IP name of the machine hosting the database server.</P
></DD
><DT
><TT
CLASS="LITERAL"
>DSN</TT
>, <TT
CLASS="LITERAL"
>Driver</TT
></DT
><DD
><P
>In your connection string, you can decide to use a DSN entry in <TT
CLASS="FILENAME"
>odbc.ini</TT
> using the <TT
CLASS="LITERAL"
>DSN</TT
> attribute, or to specify the driver you want with the <TT
CLASS="LITERAL"
>Driver</TT
> attribute.</P
></DD
></DL
></DIV
><P
>In sum, <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> supports three ODBC three choices:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><P
><B
>ODBC configuration choices</B
></P
><DL
><DT
>DSN-less</DT
><DD
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>No</I
></SPAN
> connection information is specified in <TT
CLASS="FILENAME"
>odbc.ini</TT
>.  Advantageous if you're using more of <SPAN
CLASS="PRODUCTNAME"
>FreeTDS</SPAN
> than just the ODBC driver.</P
></DD
><DT
>ODBC-only</DT
><DD
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>All</I
></SPAN
> connection information
						is specified in <TT
CLASS="FILENAME"
>odbc.ini</TT
>, without the need for <TT
CLASS="FILENAME"
>freetds.conf</TT
>.  This is the <SPAN
CLASS="QUOTE"
>"traditional"</SPAN
> ODBC setup.</P
></DD
><DT
>ODBC-combined</DT
><DD
><P
>Connection information maintained in <TT
CLASS="FILENAME"
>freetds.conf</TT
>.  <TT
CLASS="FILENAME"
>odbc.ini</TT
> contains DSN entries that refer to servernames in <TT
CLASS="FILENAME"
>freetds.conf</TT
>.</P
></DD
></DL
></DIV
><P
><DIV
CLASS="TIP"
><P
></P
><TABLE
CLASS="TIP"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TH
ALIGN="LEFT"
VALIGN="MIDDLE"
><B
>Library or Driver?</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>What's a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>library</I
></SPAN
> and what's a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>driver</I
></SPAN
>?  Technically, they're the same thing: bodies of subroutines whose names are exported to a linker (static or runtime).  By convention, a <SPAN
CLASS="QUOTE"
>"library"</SPAN
> is used directly by an application, whose programmer will require documentation and header files.  A <SPAN
CLASS="QUOTE"
>"driver"</SPAN
>, by contrast, is defined by a binary API and is used in some kind of framework, hence <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>printer driver</I
></SPAN
> and <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>video driver</I
></SPAN
>.  </P
><P
>An ODBC driver is a hybrid.  For the most part, an application relies on a driver manager to define manifest constants, and links to the DM's library.  But because the ODBC specification leaves behavior up to the driver, the application is forced to include the driver's header files, too, to exploit driver-specific functions.  </P
></TD
></TR
></TABLE
></DIV
></P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="confirminstall.htm"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.htm"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="odbcconnattr.htm"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Confirm the installation</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Connection attributes</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>