PDF de programación - Capítulo 7 : Acceso a bases de datos locales: BDE/IAPI y ODBC

Capítulo 7 : Acceso a bases de datos locales: BDE/IAPI y ODBC

7. ACCESO A BASES DE DATOS

LOCALES: BDE/IDAPI Y ODBC

7.1 IDAPI/BDE

7.1.1 Introducción

La mayoría de los sistemas que hacen uso de las Tecnologías del Habla para
proporcionar servicios de valor añadido necesitan acceder a bases de datos. Un sistema
de generación de aplicaciones telefónicas que no contemple este aspecto estaría muy
limitado en su funcionalidad, puesto que no tendría acceso a más información de la que
estuviera disponible en ficheros de texto o de voz almacenados en el propio PC sobre el
que está implementada la aplicación telefónica.

El sistema monolínea contaba con la posibilidad de acceder a bases de datos a
través del paquete software BDE (Borland Database Engine), diseñado para
proporcionar a los diseñadores de aplicaciones Windows facilidades de acceso a
múltiples bases de datos mediante una única API. La API que ofrece este paquete
software se denomina IDAPI (Integrated Database Application Program Interface).

Las razones por las que, en su momento, se escogió IDAPI fueron las siguientes:

• Permite acceder a todo tipo de bases de datos, independientemente del
formato en que estas estén creadas. Esto es fundamental, pues no parece
lógico tener que implementar funciones ‘a medida’ para cada tipo de base de
datos a la que queramos acceder.

• Permite acceder tanto a bases de datos locales como a otras residentes en un

Host (remotas).

• Proporciona acceso directo a las fuentes de datos, sin necesidad de

importarlos o exportarlos, o utilizar DDE (Dynamic Data Exchange).

• El acceso a las bases de datos se realiza a través de sentencias SQL
(Structured Query Language) o QBE (Query By Example). Ambos lenguajes
resultan muy útiles, cada uno por razones diferentes. SQL está muy
extendido y no resulta excesivamente complicado de manejar. Respecto a
QBE, resulta muy útil para usuarios sin conocimientos previos, permitiendo
componer una consulta señalando sobre los campos de las tablas existentes
en la base de datos, de forma visual. Gracias a estos lenguajes (utilizaremos

Pág. 7-1

Capítulo 7 : Acceso a bases de datos locales: BDE/IAPI y ODBC

SQL en exclusiva) no sólo podremos realizar búsquedas sobre las bases de
datos, sino también actualizaciones, inserciones, borrados, etc.

• Soporta ODBC (Open DataBase Connectivity).

Debido a todas estas ventajas se tomó la decisión de implementarlas en el
sistema multilínea, aunque su funcionamiento queda restringido a una utilización
monolínea.

Veamos algunos detalles necesarios para comprender su funcionamiento. Para
información consultar el proyecto de Mónica Fernández Pérez
(ver

más
BIBLIOGRAFÍA).

7.1.2 Arquitectura de BDE

BDE tiene una arquitectura basada en el manejo de diferentes drivers, uno por
cada tipo de base de datos que se desee manejar. Además, se ha diseñado siguiendo una
filosofía orientada a objetos, lo que facilita su ampliación. Si queremos que sea capaz de
acceder a un tipo diferente de base de datos, basta instalar el driver BDE adecuado, o el
driver ODBC correspondiente a la misma.

Además, este producto es muy útil en aplicaciones en entorno cliente/servidor,
pues proporciona un acceso transparente a la aplicación, tanto a bases de datos locales
como remotas.

7.1.3 IDAPI

IDAPI es la API de BDE. Está formada por un conjunto de funciones que
pueden ser utilizadas por cualquier lenguaje de programación capaz de manejar DLLs
de Windows, aunque está optimizado para trabajar con C/C++.

Al igual que BDE, IDAPI se ha diseñado según una filosofía orientada a objetos.
Debido a esto, las aplicaciones que la manejen utilizan una serie de objetos, entre los
que destacan:

• Drivers: cada driver es cargado automáticamente en el momento en que una
aplicación requiere de éste una acción concreta. En ese momento, todos
aquellos parámetros configurables relativos al mismo que se encuentren en el
fichero de configuración de IDAPI se utilizan para inicializarlo.

• Bases de datos: una base de datos se maneja a través de un handle al objeto,
que es creado en el momento en el que se le ordena a IDAPI abrir una base
de datos.

• Cursores: son los que permiten acceder a los contenidos de las tablas de una
base de datos o a los resultados de la ejecución de una consulta (query).
Todas las operaciones de manipulación de datos y de posicionamiento en la

Pág. 7-2

Capítulo 7 : Acceso a bases de datos locales: BDE/IAPI y ODBC

tabla se realizan a través del cursor. Se puede cerrar un cursor en cualquier
momento, también es posible tener simultáneamente abiertos varios cursores
sobre una misma tabla.

• Querys: estos objetos contienen un query (sentencia SQL válida) cuya
validez ya ha sido comprobada por BDE, dispuesto a ser enviado para su
ejecución.

7.1.4 Funciones de manejo de bases de datos basadas en
IDAPI

Las funciones añadidas son todas funciones internas, y se encargan de gestionar

el acceso a diferentes tipos de datos. Estas son las siguientes:

• IDAPI_ABRE_BD: abre la base de datos solicitada. Requiere los siguientes
parámetros de entrada: nombre de la base de datos que se quiere abrir, tipo
de base de datos de que se trata, y la clave de acceso a la base de datos, si es
necesaria. Retorna 0 si la función se desarrolló correctamente y un valor
negativo en caso de error.

• IDAPI_CIERRA_BD: cierra una base de datos. Requiere los siguientes
parámetros de entrada: nombre de la base de datos a cerrar y su tipo. Retorna
0 si la función se desarrolló correctamente y un valor negativo en caso de
error.

• IDAPI_BUSCAR: ejecuta una sentencia SQL (consulta, actualización,
inserción, borrado, etc.). Requiere los siguientes parámetros de entrada:
nombre de la base de datos, tipo de la base de datos y el query a ser
ejecutado. Retorna 0 si la función se desarrolló correctamente y un valor
negativo en caso de error.

• IDAPI_LEER_CAMPOS: lee los datos almacenados en el cursor que
devuelve IDAPI como resultado de una consulta a una base de datos. No
requiere ningún parámetro de entrada y los parámetros de salida serán los
datos correspondientes a la posición a la que está apuntando el cursor en ese
momento. Retorna 0 si la función se desarrolló correctamente, 1 si era el
último registro de datos disponible y un valor negativo en caso de error.

Estas funciones, en caso de producirse un error durante su ejecución, generan un
fichero llamado ‘DB_error.txt’ en el que se guarda información relativa a la función que
falló, la causa del fallo y la fecha en que se produjo. Este fichero se crea, caso de no
existir, en el directorio en que se esté ejecutando la aplicación telefónica.

En el caso de utilizarse el servidor IDAPI (se describe en el siguiente apartado),
no son funciones internas, sino funciones predefinidas, pues es necesario que dispongan
de función idle para realizar la espera no bloqueante de la respuesta del servidor. En este
caso, la función idle se limita a esperar la respuesta del servidor, para proceder a leer los
resultados, si lo hay, y el código de retorno de la función ejecutada por el servidor.

Pág. 7-3

Capítulo 7 : Acceso a bases de datos locales: BDE/IAPI y ODBC

7.1.5 Desventajas de IDAPI. Servidor IDAPI

Aparte de la dependencia del paquete software Borland Database Engine
(BDE), la realidad era que se estaba utilizando BDE para acceder vía ODBC (Open
DataBase Connectivity); por lo que teníamos una capa software de la que no se utilizaba
ningún servicio, ni se obtenía ningún beneficio.

Por otra parte, BDE/IDAPI no nos sirve para implementar un funcionamiento
multilínea en el acceso a bases de datos, pues una llamada a cualquiera de sus funciones
bloquea el sistema operativo hasta que se cursa la petición, por lo que nuestro sistema se
queda en el punto en el que se produce la llamada, bloqueando al resto de las líneas.

Es de destacar que existe una función de CALLBACK en IDAPI que, mientras
está procesando una petición, hace llamadas a una función definida por el usuario.
Desgraciadamente, la dispersión de valores en los intervalos entre llamadas hace
inviable su utilización para dar tiempo al sistema multilínea mientras se realiza el
acceso a la base de datos.

Llegados a este punto se decidió ensayar una solución que había sido probada
con éxito en el caso del acceso al Host IBM (se verá en el siguiente capítulo),
consistente en crear un ejecutable independiente que actúe de servidor, con el objetivo
de aprovechar
los servidores
desarrollados son multilínea, pero sólo atienden una línea a la vez. Es decir, si mientras
están procesando una petición de una línea, llega otra petición de otra línea, no será
atendida hasta que se acabe con la petición actual. Se podía haber realizado un servidor
por línea, pero hay dos razones para no hacerlo:

la multitarea cooperativa de Windows. Todos

• Sencillez y facilidad de expansión. Con el diseño actual no hay que hacer

ninguna modificación para atender más líneas en el futuro.

• No existe una necesidad real, pues la única consecuencia negativa de la
implementación adoptada es el pequeño retardo que se puede introducir,
décimas de segundo, retardo que resulta imperceptible para el usuario.

La idea es que el sistema realice una petición al servidor y se quede esperando la
respuesta, pero que esta espera no sea bloqueante. Es decir, que continúe atendiendo a
todas las líneas y, de vez en cuando, consulte si ha llegado la respuesta.

De esta forma, el que se queda bloqueado es el servidor, per