Por: Nick Gorham
Artículo Original: https://www.unixodbc.org/odbcinst.html
Propósito
Mucha gente está usando unixODBC pero por varias razones no están construyendo la configuración GUI y las herramientas de prueba (ODBCConfig y DataManager). Este documento está dirigido a estas personas y pretende explicar lo que necesitas hacer y cuándo hacerlo.
¿Qué es un archivo ini?
ODBC apareció por primera vez en Windows 3.0. En esa época, Windows utilizaba archivos .ini para contener información de configuración. Se trata de archivos de texto que contienen la siguiente disposición
[Sección 1] entry1 = value entry2 = value [Sección 2] entry1 = value entry2 = value ...
Con la llegada de Windows NT, estos archivos ini han sido sustituidos por el registro, pero la API para acceder a ellos en ODBC sigue siendo la misma. Windows tiene dos funciones en odbcinst.dll que permiten a las aplicaciones y drivers consultar y modificar estos ficheros, SQLGetPrivateProfileString y SQLPutPrivateProfileString.
Como parte del objetivo de unixODBC de reproducir el entorno ODBC en plataformas no Windows, los archivos ini y libodbcinst proporcionan el mismo formato y funcionalidad.
Sistema frente a usuario
ODBC distingue entre dos tipos de archivos ini. Los archivos ini de sistema están diseñados para ser accesibles pero no modificables por cualquier usuario, y los archivos de usuario son privados para un usuario en particular, y pueden ser modificados por ese usuario.
Los archivos del sistema son odbcinst.ini y odbc.ini (sin punto a la izquierda), y el archivo de usuario es ~/.odbc.ini en el directorio personal de cada usuario (sin punto a la izquierda).
El archivo de sistema odbcinst.ini contiene información sobre los controladores ODBC disponibles para todos los usuarios, y el archivo odbc.ini contiene información sobre los DSN disponibles para todos los usuarios. Estos "DSN's de sistema" son útiles para aplicaciones como servidores web que pueden no estar ejecutándose como un usuario real y por lo tanto no tendrán un directorio home que contenga un fichero .odbc.ini.
Un buen ejemplo de esto es Apache y PHP con soporte ODBC. Cuando el servidor http se inicia por primera vez, llama a SQLAllocEnv como root. Luego, en un momento posterior, cambia al usuario especificado (en mi caso nadie) y llama a SQLConnect. Si el DSN no era un DSN del sistema entonces esto falla.
FILEDSN's
ODBC 3 también tiene un tercer tipo de DSN, un DSN de fichero. Estos almacenan la información de conexión en un fichero al que cualquiera puede acceder. unixODBC no soporta por el momento FILEDSN's pero lo hará cuando lo haga. Son cosas útiles pero menos útiles para UNIX que para NT. Debido a la visión de MS de que todo el mundo debería tener Windows en su escritorio, cada estación de trabajo tendrá su propio registro con su propio conjunto de DSN's de sistema y de usuario que no pueden ser usados por otras estaciones de trabajo. Los DSN de archivo son una solución para permitir que la información se almacene en un servidor central al que puedan acceder todas las estaciones de trabajo.
¿Por qué no "vi"?
Todos los ficheros de configuración que necesita unixODBC son ficheros de texto plano, así que no hay razón para que no puedas usar tu editor de texto favorito para configurar los ficheros.
Sin embargo desde la beta 1.6 la localización de los ficheros de sistema odbcinst.ini y odbc.ini son determinados por el script "configure". La ubicación por defecto es /usr/local/etc, y si se especifica un prefijo la ubicación es {prefijo}/etc. La ubicación de la ruta etc puede separarse del árbol de prefijos normal especificando --sysconfdir=DIR, por lo que lo siguiente esperará que los archivos del sistema estén en la misma ubicación que en las compilaciones anteriores a la 1.6.
./configure --sysconfdir=/etc
El resultado de todo esto es que si utiliza odbcinst para configurar los archivos puede estar seguro de que se utilizará la misma ruta a los archivos que utiliza el gestor de controladores, por lo que las modificaciones surtirán efecto.
¿Qué contienen?
Bien, ya conocemos un poco la historia de los archivos ini y ODBC, así que ahora tenemos que llegar a la parte que es realmente útil. Lo que se pone en ellos.
odbcinst.ini
Este contiene un encabezado de sección que proporciona un nombre para el controlador, por lo que para el ejemplo a continuación PostgreSQL para indicar un controlador Postgres. Las siguientes líneas contienen una descripción y luego los bits importantes. Las rutas Driver y Setup apuntan al driver ODBC y a las librerías Setup. La librería de configuración se usa cuando pulsas en Add en ODBCConfig para añadir un nuevo DSN, pero como este documento trata sobre no usar las herramientas GUI, esto no es tan importante para nosotros. Mucho más importante es la entrada Driver (vital de hecho) Esta es la librería que el gestor de drivers cargará dinámicamente cuando se llame a SQLConnect o SQLDriverConnect para ese DSN. Si esto apunta a un lugar incorrecto el DSN no funcionará. Si dlopen() falla el DSN no funcionará. La entrada "fileusage" es añadida por el programa odbcinst, asi que si estas usando un editor de texto, necesitaras añadirla tu mismo.
[PostgreSQL] Descripción = Controlador PostgreSQL para Linux y Win32 Controlador = /usr/local/lib/libodbcpsql.so Configuración = /usr/local/lib/libodbcpsqlS.so UsoArchivo = 1
templates
odbcinst espera recibir un archivo de plantilla. Si está añadiendo un controlador para la entrada anterior, el archivo de plantilla contendría lo siguiente
[PostgreSQL] Descripción = Controlador PostgreSQL para Linux y Win32 Controlador = /usr/local/lib/libodbcpsql.so Configuración = /usr/local/lib/libodbcpsqlS.so
e invocarías odbcinst con los siguientes argumentos, suponiendo que has creado un archivo template_file con las entradas anteriores.
odbcinst -i -d -f template_file
Los argumentos para odbcinst son los siguientes
-i instalar
-d controlador
-f nombre del archivo de plantilla
Threads
Desde la versión 1.6, si el gestor de controladores se construyó con soporte de hilos, puede añadir otra entrada a cada entrada de controlador. Por ejemplo
[PostgreSQL] Descripción = Controlador PostgreSQL para Linux y Win32 Controlador = /usr/local/lib/libodbcpsql.so Configuración = /usr/local/lib/libodbcpsqlS.so Enhebrado = 2
Esta entrada altera el nivel de serialización de hilos por defecto. Puede encontrar más detalles en el archivo DriverManager/__handles.c del árbol de fuentes.
[.]odbc.ini
El contenido de los archivos odbc.ini es un poco más complicado, pero siguen el mismo formato que las entradas odbcinst.ini. Esto se complica porque cada controlador requiere entradas diferentes. Las entradas para todos los controladores suministrados con la distribución se incluyen a continuación como referencia. Las entradas se pueden añadir de la misma manera utilizando odbcinst, o un editor de texto. Una entrada de ejemplo para el controlador anterior podría ser
[PostgreSQL] Descripción = Prueba a Postgres Controlador = PostgreSQL Rastreo = Sí Archivo TraceFile = sql.log Base de datos = nick NombreServidor = localhost NombreUsuario = Contraseña = Puerto = 5432 Protocolo = 6.4 Sólo lectura = No RowVersioning = No ShowSystemTables = No ShowOidColumn = No FakeOidIndex = No ConnSettings =
Y esto puede escribirse en un archivo de plantilla, e insertarse en el archivo ini para el usuario actual mediante
odbcinst -i -s -f template_file
Las entradas individuales, por supuesto, pueden variar.
La línea Driver se utiliza para que coincida con la entrada [section] en el archivo odbcinst.ini y la línea Driver en el archivo odbcinst se utiliza para encontrar la ruta de la biblioteca de controladores, se carga y se establece la conexión. Es posible sustituir la entrada del controlador por una ruta al propio controlador. Esto puede usarse, por ejemplo, si el usuario no puede obtener acceso root para configurar nada en /etc (menos importante ahora debido a la ruta movible etc). Por ejemplo
[PostgreSQL] Descripción = Prueba a Postgres Controlador = /usr/local/lib/libodbcpsql.so Rastreo = Sí Archivo de seguimiento = sql.log Base de datos = nick Nombre del servidor = localhost NombreUsuario = Contraseña = Puerto = 5432 Protocolo = 6.4 Sólo lectura = No RowVersioning = No ShowSystemTables = No ShowOidColumn = No FakeOidIndex = No ConnSettings =
Templates
Los templates de los controladores incluidos son...
PostgreSQL
[Postgres] Descripción = Prueba a Postgres Controlador = PostgreSQL Rastreo = Sí Archivo TraceFile = sql.log Base de datos = nick NombreServidor = localhost NombreUsuario = Contraseña = Puerto = 5432 Protocolo = 6.4 Sólo lectura = No RowVersioning = No ShowSystemTables = No ShowOidColumn = No FakeOidIndex = No ConnSettings =
Mini SQL
[Mini SQL] Description = MiniSQL Driver = MiniSQL Trace = No TraceFile = Host = localhost Database = ConfigFile =
MySQL
[MySQL-test] Descripción = Base de datos de prueba MySQL Rastreo = Desactivado TraceFile = stderr Controlador = MySQL SERVIDOR = 192.168.1.26 USUARIO = pharvey CONTRASEÑA = PUERTO = 3306 BASE DE DATOS = test
NNTP driver
[nntp Data Source] Descripción = nntp Driver Controlador = Controlador nntp Rastreo = No TraceFile = Host = localhost Base de datos = Puerto =
FreeTDS driver
Controlador = TDS Descripción = Base de datos de muestras Northwind Rastreo = No Servidor = 192.168.1.25 Base de datos = Northwind UID = sa
Sybase SQL Anywhere 5.0
Gracias.
[Sybase SQL Anywhere 5.0] Controlador=Sybase SQL Anywhere 5.0 Descripción=Controlador ODBC de Sybase SQL Anywhere 5.0 Usuario=dba Contraseña=sql Archivo de base de datos=sademo.db
Espero que esto le sirva a alguien... Nick Gorham ([email protected])
