ODBC para Servidor de Bases de Datos PostGreSQL ( I )

Autor:
Juan Antonio Martinez Castaño

Indice:

Presentación
Introducción
Instalación de PostGreSQL
Un primer paseo por el API ODBC
El API ODBC en Linux
Conclusiones
Referencias

Presentación

Una vez demostrado que como servidor de ficheros Linux no tiene
rival, y que como servidor de InterNet no tiene nada que envidiar a los
grandes sistemas, hoy vamos a tratar un otro apartado en el que linux se
desenvuelve sin problemas: el de los servidores de bases de datos para
redes de PC's

Introducción

Los usuarios de MS-Windows en entornos ofimáticos se encuentran con
frecuencia con el problema del acceso remoto a bases de datos. Efectivamente
MS-Dos y Windows nunca fueron pensados como sistemas de red. Incluso, cuando
no hubo mas remedio, las soluciones no dejaron de ser sino un parche... Del
mismo modo las bases de datos eran locales, con soluciones propietarias.

Por otro lado, los grandes sistemas llevan trabajando desde hace
años con servidores de bases de datos. Accesos concurrentes,
transacciones, bloqueos, rollback, etc, son procesos largamente
conocidos y estudiados. El acceso de la informatica personal a las redes
locales trajo al mundo ofimático los mismos problemas a los que
los grandes mainframes se habían enfrentado hacia años.
Solo había un problema: El sistema operativo. En efecto: todas
las aplicaciones desarrolladas partíian de la base de un sistema
operativo monotarea monousuario, sin servicios de red, y casi sin
ningún tipo de control de acceso a los recursos. Incluso en la
actualidad, Windows 95 tiene problemas con el accesso a recursos entre
aplicaciones ( o si no, probad a abrir un documento con Word97 y
-sin cerrar el documento- abriendo una ventana de MS-Dos intentad hacer
alguna operación con dicho documento. !!Haced primero un backup!! )

Los primeros intentos de acceso concurrente a bases de datos desde PC's
se realizan mediante recursos de compartición de archivos. Se utilizan
los controles de acceso de NetBIOS para salvaguardar la consistencia de
datos... falta todavía un paso: el convertir los programas de
gestión de bases de datos a una arquitectura cliente-servidor,
donde un proceso maestro es el que controla cada petición de acceso
a la base de datos, y nuestro dBase, Paradox o Access no son sino
user-interfaces de visualizacion de datos.

Tenemos pues diferentes enfoques, en función de la separación
entre la aplicación y los ficheros de datos y de la relación que
se establece entre ellos:

Cliente y servidor son la misma aplicación, siendo los
datos referidos a un fichero con formato propietario, y usado
éste en monousuario. Ejemplo: un usuario que crea y maneja
un fichero de dBase
Cliente y servidor son la misma aplicación, pero los
datos son compartidos a través del sistema de ficheros.
Ejemplo: una red de usuarios de dbase que acceden via NetBIOS a
mismo fichero de datos
El Cliente constituye un user interface, pero los datos
provienen de una database "genérica", residente en la
misma maquina, y que son accedidos a traves de un driver que
convierte los datos de la database en algo que el cliente entiende:
por ejemplo, cuando desde Access, vinculamos una base de datos con
otra escrita, por ejemplo en dBase
Cuando el vínculo no se realiza no a traves del sistema
de ficheros sino con un servidor remoto, via red local, tenemos
un sistema servidor de bases de datos.

�Cómo se establecen estos vínculos? En los grandes sistemas,
y en las redes UNIX, desde el primer momento los clientes son aplicaciones
independientes del servidor, hablan su lenguaje y se entienden de tú
a tú con él. En sistemas basados en MS-Dos ( ej. Windows )
se hace necesario el proveer un interfaz entre la aplicación y
los servidores. Del mismo modo, en los sistemas UNIX todo el mundo habla
el mismo lenguaje de bases de datos -SQL-, mientras que los PC's están
plagados de soluciones propietarias, en función de la aplicación
y del fabricante. Se hace pues necesaria una arquitectura en capas para
realizar las siguientes tareas:

Una capa para que la aplicación sea capaz de hablar
con el Sistema Operativo a través de un API común
Una capa en el Sistema Operativo que se encarga de discernir el
tipo de acceso - a sistema de ficheros, a databases de otro
proveedor, a un servidor remoto...- y de invocar al driver adecuado
Un driver que se encarga del acceso a los datos, y de su
conversión al API común del sistema operativo
Si el acceso se efectúa vía red local hacia un
servidor remoto, todavía hace falta una capa nueva en el
lado del servidor: la que convierte las peticiones del cliente
al API de programación que este provee.

Para conseguir esta funcionalidad Microsoft definió en su día
un API denominado Open DataBase Conectivity ( ODBC ). Toda
aplicación de bases de datos que se precie para el mundo Windows
debe ser capaz de implementar y manejar el API de acceso a la base de datos

Microsoft ha hecho público el API de programación por lo que
-en teoría- cualquiera puede escribir un driver ODBC, las aplicaciones
de databases que hablen ODBC puedan comunicarse con un servidor, bien sea
local, remoto, fichero, aplicación o incluso otro programa de bases
de datos que se esté ejecutando en la misma máquina ( esta es
la teoría. Microsoft, siguiendo su política habitual, tiene
la mala costumbre de saltarse sus propios estándares, y algunas
aplicaciones suyas manejan extensiones al ODBC propias y no documentadas... )

Rizando el rizo, y puesto que ODBC es un estandard "de facto", el cliente
de la base de datos no tiene siquiera por que ser un sistema de Microsoft.
De hecho, existe un proyecto de colaboración en la comunidad InterNet
para proveer a los sistemas UNIX de un API de acceso ODBC unificado para sus
bases de datos. Uno podría preguntarse cúal es el sentido de
todo esto, pues SQL tiene ya un API definido, y todos los UNIX saben hablar
en SQL, pero se entiende fácilmente si pensamos que si el API de
acceso a la base de datos es el mismo en Windows y en UNIX, el trabajo de
porting se reduce considerablemente. Es mucho mas fácil convencer
a los desarrolladores de bases de datos en Windows para que porten a Linux
sus aplicaciones si se les proporciona el mismo API de programación,
de manera que solo tengan que teclear "make"

ODBC no es sino un API de conectividad entre aplicaciones de bases de datos cliente y servidor. Dicho API esta organizado en varias capas: de aplicacion, de sistema, y de acceso.

En resumen: ODBC no es sino un API de conectividad entre aplicaciones
de bases de datos cliente y servidor. Dicho API esta organizado en varias
capas: de aplicacion, de sistema, y de acceso.

Hemos dividido este tema en dos partes:

En este artículo, hacemos una pequeña
introduccóon al API ODBC, y emprendemos la instalación
de una de las bases de datos mas conocidas en el mundo Linux:
PostGreSQL, asi como de las bibliotecas y drivers de ODBC para
UNIX.
En el próximo número de LINUX ACTUAL, haremos
una descripción mas detallada del API de ODBC, incluyendo
ejemplos que podemos compilar y ejecutar desde Linux, y emprenderemos
la tarea de utilizar una base de datos remota desde sistemas MS-Windows
conectados en red con nuestro servidor. En breve, nuestro jefe ya no
tendrá más excusas para mantener un servidor NT en la
oficina... ;-)

Todos los ejemplos, gráficos y listados de estos artículos
han sido realizados con PostGreSQL 6.3.2 en una Sparc-SLC con RedHat 4.2
SparcLinux y un Pentium 166MMX con Linux RedHat 5.0 , Windows 95 OSR2 y
Office 97, conectados en red. En el CD-Rom se incluyen los fuentes y paquetes
instalables de las últimas releases oficiales de los programas
que aquí se explican, existentes en el momento de escribir el articulo

Instalación de PostGreSQL-6.3.2 bajo Linux

En el número 2 de Linux Actual se describió la
instalación de MySQL como servidor de bases de datos. En este
artículo se describe la instalación de PostGreSQL 6.3.2,
con lo que los lectores tendrán así ocasión de poder
establecer criterios para seleccionar su servidor favorito.

Si utilizamos una distribución tipo RedHat tendremos
los siguientes paquetes:

postgresql-6.3.2-3.i386.rpm	Paquete básico
postgresql-devel-6.3.2-3.i386.rpm	API de programación PostGreSQL
postgresql-clients-6.3.2-3.i386.rpm	Clientes bajo Linux
postgresql-data-6.3.2-3.i386.rpm	Templates para bases de datos
postgresql-jdbc-6.3.2-3.i386.rpm	Interfaz con Java Database Conectivity (JDBC)
postgresql-perl-6.3.2-3.i386.rpm	Interfaz con Perl

Para instalarlos, no tendremos más que montar el CDROM y ejecutar:

root@cochito:/mnt/cdrom# rpm -v -i ${path_to_rpms}/postgresql*i386.rpm

En el caso de que ya tengamos una versión pre-instalada, es recomendable
hacer el upgrade a ésta, por lo que deberemos añadir la
opción --upgrade a la línea de comandos

En el caso de que no dispongamos de las utilidades de paquetería rpm,
procederemos a coger el paquete .tar.gz y compilarlo. Para ello procederemos
de la siguiente forma:

Creamos un usuario "postgres" bajo cuyo uid se
ejecutará todo el software de gestión de la database.
! Bajo ningún concepto ejecutaremos nunca dicho software con
permisos de root !. Asimismo creamos el directorio de spool donde
se van a guardar las databases del sistema:

[root@sparky /root]# grep postgres /etc/passwd /etc/group
/etc/passwd:postgres:!:100:101:PostGreSQL Server:/var/lib/pgsql:/bin/bash
/etc/group:postgres::101:
[root@sparky /root]# ls -la /var/lib/pgsql  
total 3
drwxr-xr-x   2 postgres postgres     1024 May 23 20:40 .
drwxr-xr-x   8 root     root         1024 May 23 20:13 ..
-rw-r--r--   1 postgres postgres       18 May 23 20:40 .bash_history

Como root descomprimimos el paquete en el directorio deseado.
( normalmente /usr/local/src ).
En el caso de que ya tuviéramos una versión de
PostGreSQL instalada anteriormente, deberemos hacer un backup
de las bases de datos existentes en el sistema. Remitimos al lector a los
ficheros "INSTALL" que acompañan al paquete

Ejecutamos:


[root@sparky /usr/local/src/postgresql-6.3.2/src]# ./configure 
[root@sparky /usr/local/src/postgresql-6.3.2/src]# make

Es posible que deseemos modificar alguno de los parámetros de
compilacion El comando "configure --help" y la documentación
nos indican las diversas opciones. Especial mención merecen las
opciones "--template", "--php", y "--perl".
Consultar el fichero INSTALL para escoger los parámetros
adecuados.
El programa debería compilar sin problemas. Una vez finalizada la
compilación "make install" nos instalará
PostGreSQL en los directorios escogidos.

En el caso de que no hayamos desactivado expresamente su
generacisóon, se habrá creado la librería
libpq.so.x.x . Deberemos añadir en el fichero
/etc/ld.so.conf el path donde la hayamos instalado, y acto seguido
ejecutaremos ldconfig para actualizar el cache del cargador de
librerías dinámicas

En los ficheros /etc/profile.d/postgresql.sh y
/etc/profile.d/postgresql.csh instalamos los paths y las variables
de entorno apropiadas:

[root@sparky /root]# cat /etc/profile.d/postgresql.sh
PATH=$PATH:/usr/local/pgsql/bin
MANPATH=$MANPATH:/usr/local/pgsql/man
PGLIB=/usr/local/pgsql/lib
PGDATA=/var/lib/pgsql/data
export PATH MANPATH PGLIB PGDATA

[root@sparky /root]# cat /etc/profile.d/postgresql.csh
setenv PATH $PATH:/usr/local/pgsql/bin
setenv MANPATH $MANPATH:/usr/local/pgsql/man
setenv PGLIB /usr/local/pgsql/lib
setenv PGDATA /var/lib/pgsql/data

Creamos los "esqueletos" de la database. Para ello hacemos
"su - postgres" y ejecutamos "initdb"
configuramos adecuadamente los ficheros de control de PostGreSQL,
especialmente el fichero de control de accesos pg_hba.conf . De
nuevo, nos remitimos al manual..
El manual recomienda, antes de empezar a trabajar, ejecutar los programas
de testing. Para ello deberemos arrancar el servidor en modo test, y
ejecutar make en el directorio de testing. ( Leer fichero
INSTALL )

Finalmente, creamos el fichero /etc/rc.d/init.d/postgresql y
configuramos con el "runlevel editor" el arranque en power-on

del servidor de la base de datos. El listado 1 nos muestra un ejemplo de
script de arranque para RedHat-5.0:

#! /bin/sh # chkconfig: 345 85 15 # description: Starts and stops the PostgreSQL # backend daemon that handles # all database requests. # Source function library. . /etc/rc.d/init.d/functions # Get config. . /etc/sysconfig/network # Check that networking is up. # Pretty much need it for postmaster. [ ${NETWORKING} = "no" ] && exit 0 [ -f /usr/bin/postmaster ] \|\| exit 0 # See how we were called. case "$1" in start) echo -n "Starting postgresql service: " su postgres -c \ '/usr/bin/postmaster -S -i -D/var/lib/pgsql' sleep 1 pid=`pidof postmaster` echo -n "postmaster [$pid]" touch /var/lock/subsys/postmaster echo ;; stop) echo -n "Stopping postgresql service: " killproc postmaster sleep 2 rm -f /var/lock/subsys/postmaster echo ;; status) status postmaster ;; restart) $0 stop $0 start ;; *) echo "Usage: postgres.init {start\|stop\|status\|restart}" exit 1 esac exit 0
Listado 1: fichero de arranque en power-on de PostGreSQL

#! /bin/sh
# chkconfig: 345 85 15
# description:  Starts and stops the PostgreSQL 
#		backend daemon that handles
#               all database requests.

# Source function library.
. /etc/rc.d/init.d/functions

# Get config.
. /etc/sysconfig/network

# Check that networking is up.
# Pretty much need it for postmaster.
[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/bin/postmaster ] || exit 0

# See how we were called.
case "$1" in
  start)
        echo -n "Starting postgresql service: "
        su postgres -c \
		'/usr/bin/postmaster -S -i -D/var/lib/pgsql'
        sleep 1
        pid=`pidof postmaster`
        echo -n "postmaster [$pid]"
        touch /var/lock/subsys/postmaster
        echo
        ;;
  stop)
        echo -n "Stopping postgresql service: "
        killproc postmaster
        sleep 2
        rm -f /var/lock/subsys/postmaster
        echo
        ;;
  status)
        status postmaster
        ;;
  restart)
        $0 stop
        $0 start
        ;;
  *)
        echo "Usage: postgres.init {start|stop|status|restart}"
        exit 1
esac

exit 0

Listado 1: fichero de arranque en power-on de PostGreSQL

Arrancamos el sistema con "/etc/rc.d/init.d/postgresql start"
Como usuario "postgres" vamos a crear una cuenta de acceso para i
poder trabajar con el servidor de base de datos. Estas cuentas son
exclusivas de la base de datos, y no hacen referencia a usuarios reales
del sistema, aunque es bastante común tener una cuenta generica
"sqluser" sin login, para uso exclusivo de PostGreSQL.
Esto lo haremos con el comando

[postgres@sparky:/var/lib/pgsql]$ createuser sqluser

El programa createuser nos irá preguntando por los diversos
privilegios de dicho usuario, su uid ( que -de nuevo-, no tiene por
qué coincidir con el de un usuario real, aunque así sea en
nuestro ejemplo ). Los diversos ficheros de configuración,
indicarán qué usuarios tienen permiso para hacer qué
cosas. De nuevo, para una descripción detallada, nos remitimos al
manual

En el caso de que nuestra base de datos vaya a ser utilizada desde
el servidor de Web, mediante PHP, deberemos añadir un nuevo
usuario "nobody", con el mismo userid y groupid que el
usuario real. Recordemos que el servidor Apache se ejecuta como dicho
usuario

Si estabamos realizando un upgrade, éste es el momento
de hacer un restore de las diversas databases que tuviéramos
procedentes de una release anterior

Creamos una base de datos para "jugar". El sistema trae ya una database
generica "template1" pero ya se sabe que Murphy anda suelto, y no esta
de más un poco de precaución. La denominaremos "odbctest"

[postgres@sparky:/var/lib/pgsql]$ createdb odbctest

El Concepto de base de datos relacional va más alla de la simple tabla: una RDB engloba tablas, indices, operadores, funciones, etc, bajo un nombre común, definiendo las interrelaciones entre los diversos elementos de dicha base de datos

El concepto de base de datos en PostGreSQL, y en general en todas
las bases de datos relacionales es mucho mas amplio que el tradicional de
conjunto de registros, cada uno con "n" campos de diversos tipos.
Aquí por database se entiende una agrupación de objetos,
tales como tablas, indices, funciones operadores, etc, bajo un nombre
común

Ahora, dentro de la database "odbctest" vamos a crear una tabla con la que
trabajar. Por el momento vamos a obviar la sintaxis SQL, dejandola para un
articulo posterior, y vamos a introducir ciegamente los datos. Al final
del articulo se indican referencias sobre manuales de SQL, ( si los lectores
lo estiman oportuno, incluiremos en Linux Actual una serie sobre
dicho lenguaje ). Simplemente indicar que PostGreSQL se acompaña de un
interfaz de entrada directa de comandos SQL, denominado psql, que
utilizaremos para introducir los datos en la database. El listado 2 muestra
los datos que introduciremos en la database:

create table telefonos ( nombre char(25), direccion char(40), telefono int ); insert into telefonos values ( 'E.T.S.I.Teleco','C. Universitaria s/n',5495700 ); insert into telefonos values ( 'Linux Actual','Alfonso Gomez 42',3040622 ); insert into telefonos values ( 'Juan Antonio','Mi Casa',12345678 ); insert into telefonos values ( 'Emergencias','Comunidad de Madrid',112 );
Listado 2: programa de ejemplo de creacion de base de datos

create table telefonos (
	nombre	char(25),
	direccion char(40),
	telefono  int
);

insert into telefonos 
    values ( 'E.T.S.I.Teleco','C. Universitaria s/n',5495700 );
insert into telefonos 
    values ( 'Linux Actual','Alfonso Gomez 42',3040622 );
insert into telefonos 
    values ( 'Juan Antonio','Mi Casa',12345678 );
insert into telefonos 
    values ( 'Emergencias','Comunidad de Madrid',112 );

Listado 2: programa de ejemplo de creacion de base de datos

Para aquellos que no quieran introducir a mano los comandos, se incluye
dicho listado en el CDROM, de manera, que en lugar de teclearlo, se puede
cargar directamente desde psql con la secuencia de escape \i
(include file)

[postgres@sparky:/var/lib/pgsql]$ psql odbctest
Welcome to the POSTGRESQL interactive sql monitor:
  Please read the file COPYRIGHT for copyright terms of POSTGRESQL
  
  type \? for help on slash commands
  type \q to quit
  type \g or terminate with semicolon to execute query
You are currently connected to the database: odbctest

odbctest=> \i /path/to/cdrom/sample/sql/include/file/telefonos.sql
create table telefonos (
        nombre  char(25),
        direccion char(40),
        telefono  int
);
CREATE

insert into telefonos
        values ( 'E.T.S.I.Teleco','C. Universitaria s/n',5495700 );
INSERT 17584 1
insert into telefonos
        values ( 'Linux Actual','Alfonso Gomez 42',3040622 );
INSERT 17585 1
insert into telefonos
        values ( 'Juan Antonio','Mi Casa',12345678 );
INSERT 17586 1
insert into telefonos
        values ( 'Emergencias','Comunidad de Madrid',112 );
INSERT 17587 1

EOF
odbctest=> select nombre,direccion from telefonos 
	where telefono=5495700;
nombre                   |direccion                               
-------------------------+----------------------------------------
E.T.S.I.Teleco           |Ciudad Universitaria s/n                
(1 row)
odbctest=> \q
[postgres@sparky:/var/lib/pgsql]$

Ya tenemos nuestro servidor de databases instalado y funcionando, y hemos
creado una pequeña base de datos para empezar a trabajar. A
continuación se describirá cómo instalar las
librerías ODBC y el driver ODBC para PostGreSQL en Linux,
haciendo previamente una breve introducción al funcionamiento del
API ODBC.

Un primer paseo por el API de ODBC

Antes de emprender la instalación de ODBC es preciso aclarar algunos
conceptos de funcionamiento del API de ODBC.

Como hemos explicado en la introdución, ODBC es un API de interfaz entre
clientes de bases de datos y servidores de bases de datos. La figura 1 ilustra
este esquema:

figura 1: Estructura en capas del API ODBC

La primera capa constituye la librería del API que utilizan las
diversas aplicaciones que "hablan" ODBC. Microsoft proporciona para sus
sistemas el fichero ODBC32.DLL, que contienen el API y el interfaz
con el sistema operativo, permitiendo a los desarrolladores de controladores
ODBC incluír dicha librería en sus distribuciones ( de la
misma manera que para la DLL de controles Visual Basic VBRUN.DLL ). Para
sistemas UNIX, el proyecto FreeODBC, ha desarrollado su propia librería
GPL libodbc.so.x.x que es totalmente compatible con las especificaciones
descritas por Microsoft

El administrador de orígenes de datos es el responsable del "rutado" de
peticiones de ODBC desde la librería hasta los controladores. Para ello
se discriminan tres tipos de orígenes de datos: de usuario, de archivo
y de sistema. Esta nomenclatura es motivo frecuente de confusión: cuando
desde Windows se abre desde el panel de control el menú de
"controladores ODBC" se encuentra con esta clasificación, y cuando
abre cada una de las ventanas se encuentra con los mismos contenidos...
Vamos a explicarlo un poco:

Los orígenes de datos de usuario, realmente se refieren a las
operaciones que realiza el usuario con su base de datos desde la
aplicación nativa para la que han sido desarrollados, y sin
realizar ningún tipo de compartición con otros usuarios. En
cristiano: cuando se trabaja con MS-Access, y no compartes la base de
datos ( en UNIX y en Win-NT esta disgresión tiene sentido;
en Win95 es cuando menos discutible )
Cuando se comparte la base de datos mediante un servidor de ficheros
compartiendo físicamente los datos almacenados en un fichero
determinado hablamos de orígenes de datos de archivo. Este
método permite, por ejemplo a un usuario de dBase manejar una
database de MS-Access, o bien que varios usuarios puedan compartir
una misma database
Cuando no se comparte un fichero, sino que se trabaja con la database a
través de un sistema cliente-servidor, hablamos de un origen de
datos de sistema.
Las aplicaciones ofimáticas mas comunes, ofrecen drivers para
orígenes de datos de usuario y de archivo, para permitir a los
usuarios el poder trabajar, importar y exportar datos entre diversas
aplicaciones de gestión. Las aplicaciones de servidores de bases
de datos, por contra, proporcionan drivers para orígenes de datos
de sistema

PostODBC y los drivers de PostGreSQL para iODBC pertenecen a
esta última categoría

Por último, cada origen de datos tiene asociado un controlador,
que actúa de "pasarela" entre el API y el acceso físico a
los datos

El API de ODBC en Linux

Llegados a este punto preguntamos: �C�mo funciona de cara al programador
la librería ODBC?. La respuesta es ridículamente sencilla:
el API ODBC consiste en un interfaz que implementa un método de
pasar peticiones en lenguaje SQL a través de una serie de funciones.
Con ODBC podemos:

Obtener un puntero de descripción del entorno de programacion
( algo parecido al XOpenDisplay() de X-Windows )
Crear punteros de conexión, especificando origen de datos y
controlador
Efectuar conexiones con la database (en nuestro lenguaje: abrir un socket)
Crear punteros de peticiones SQL ( básicamente, obtener
estructuras de datos que nos permitan insertar nuestras peticiones )
Ejecutar peticiones sobre la base de datos
Recoger resultados de nuestras peticiones
Liberar y cerrar todos los recursos previamente asignados

En la práctica, ni todas las aplicaciones, ni todos los controladores de
orígenes de datos son capaces de gestionar todas las funcionalidades
previstas por el API. Por ello se establecen los denominados "niveles de
conformidad SQL" en la aplicación así como "niveles de
conformidad del controlador", que permiten al administrador de orígenes
de datos saber qué puede hacer tanto con el driver como con la
aplicación.

Remitimos al lector a la literatura indicada en las referencias para
buscar las especificaciones y descripciones de cada nivel de compatibilidad

El proyecto FreeODBC ha desarrollado una librería, denominada iODBC, que cumple con las especificaciones del API ODBC 2.0 de Microsoft, y que integra las funciones de API y de administrador de orígenes de datos.

�Cómo se aplica ésto en sistemas UNIX? El proyecto
FreeODBC ha desarrollado una librería, denominada iODBC, que
cumple con las especificaciones del API ODBC 2.0 de Microsoft, y que integra
las funciones de API y de administrador de orígenes de datos. Cada
servidor de bases de datos provee un driver que hace las funciones de
controlador de orígenes de datos y de origen de datos de sistema
específico de cada servidor de bases de datos.

Existe un fichero ${HOME}/.iodbc.ini, que indica a la librería
libodbc.so.x.x, los controladores de que dispone cada sistema, y
cómo se accede a ellos. Todo el interfaz esta implementado mediante
librerías dinámicas. El resultado de todo esto, es que el
programador se encuentra con un API virtualmente idéntico al que se
encontraría si estuviera trabajando en una maquina M$-Windows

En el CD-Rom que se acompa�a a esta revista, bajo el directorio
odbc/iodbc encontramos los siguientes ficheros:

iodbc-2.12.shar.Z Código fuente de la librería
del API de ODBC para UNIX proveniente del Proyecto FreeODBC

pgodbc-0.03.tgz Código fuente del driver UNIX para
conectar el API iODBC con el servidor PostGreSQL

Buceando por las paginas web, podremos encontrar drivers de iODBC para casi
todas las bases de datos disponibles en Linux. De hecho, Los desarrolladores
de iODBC han decidido incluír en sus nuevas releases todos los drivers
de aquellas bases de datos que libremente los provean, incluyendo además
de serie la pasarela JDBC-ODBC.

Conclusión

En este primer artículo dedicado a la conectividad ODBC, se han
introducido los conceptos básicos de dicho sistema. Asimismo hemos
aprendido a instalar y configurar Uno de los servidores de bases de datos
más conocidos: PostGreSQL, así como los drivers y
librerías ODBC para UNIX.

En el próximo número de Linux Actual,
profundizaremos en el API de ODBC, dando algunos ejemplos de
programación, y se explicará la forma en que debemos instalar
los drivers ODBC para PostGreSQL en sistemas Microsoft Windows-3.XX
y Windows-95, con ejemplos de utilización desde MS-Access-97.

Referencias

PostGreSQL:

http://www.postgresql.org

http://postgres95.vnet.net
MySQL:

http://www.tcx.se
Referencias sobre SQL:

- "The Practical SQL handbook" Bowman, Emerson y Damovsky

ISBN 0-201-44787-8 Addison-Wesley 1997

- "A guide to the SQL Standard" Date y Darwen

ISBN 0-201-96426-0 Addison-Wesley 1997
PostGreSQL ODBC:

http://www.magenet.com/postodbc

http://postgres95.vnet.net/postodbc
iODBC:

"The FreeODBC Pages" http://users.ids.net/~bjepson/freeODBC/
ODBC y JDBC:

"Gestion de Bases de Datos en Internet" Framiñan y León

ISBN 84-415-0208-0 Anaya Multimedia

Información técnica

Active forum topics