Notas sobre programación en red con la BDE

Copyright © 2001 Ernesto De Spirito

Bases de datos Paradox

Todas las aplicaciones que acceden a tablas de una misma base de datos Paradox deben usar el mismo archivo PDOXUSRS.NET. El bloqueo de registros y otras características dependen de esto. No usar el mismo archivo PDOXUSRS.NET puede resultar en datos corruptos y en pérdida de información.

El programa de instalación instala el archivo PDOXUSRS.NET en el directorio raíz del primer disco duro de cada computadora donde lo corra (C:\), y establece la configuración NET DIR en su archivo IDAPI.CFG (valdrá C:\). Por consiguiente, de modo predeterminado, todas las aplicaciones de una misma estación de trabajo (EDT) comparten el mismo archivo PDOXUSRS.NET, pero no todas las aplicaciones corriendo desde la red!

Hay dos formas de corregir esto. Una forma es cambiar el archivo IDAPI.CFG en cada EDT:

1. Ejecute el BDE Administrator (lo encontrará en el Panel de Control de Windows)
2. En el menú "Object" elija "Open configuration..."
3. Abra el archivo IDAPI.CFG
4. En la solapa "Configuration" vaya a Configuration/Drivers/Native/Paradox
5. Cambie la entrada NET DIR para apuntar a la ubicación del archivo PDOXUSRS.NET compartido. Este puede ser por ejemplo F:\ en una EDT y E:\ en otra, dependiendo de como esté configurado el mapeo de unidades en cada EDT. Para evitar la dependencia en el mapeo de unidades y usar un nombre uniforme en todas las EDTs puede usar el camino de red \\MAQUINA\RECURSO\[CAMINO\], donde MAQUINA es el nombre del servidor donde está localizado el archivo, RECURSO es el nombre del recurso compartido (un directorio) y opcionalmente CAMINO es el camino del subdirectorio donde está ubicado el archivo PDOXUSRS.NET.
    
   Si el archivo está localizado en C:\TODOS\BASEDATOS\PDOXUSRS.NET por ejemplo, en un servidor llamado "SERVIDOR" que comparte el directorio C:\TODOS bajo el nombre "COMPARTIDO", entonces el NET DIR en todas las EDT (incluyendo el servidor) debería ser \\SERVIDOR\COMPARTIDO\BASEDATOS\
6. Guardar los cambios (Object / Save As configuration).

La otra forma de hacerlo es establecer la propiedad NetFileDir del objeto Session de sus aplicaciones antes de abrir cualquier tabla o consulta. Por ejemplo:

Session.NetFileDir := '\\SERVIDOR\COMPARTIDO\BASEDATOS\';

Mejorando el rendimiento

La BDE tiene problemas serios en cuanto a rendimiento en una red, y esta es una de las razones por las cuales hay varios reemplazos de la BDE dando vuelta:

  BDE Alternatives Guide

No es mucho lo que se puede hacer para mejorar el rendimiento de la BDE, pero puede intentar algunos de los siguientes consejos para ver si ayudan.

ACTUALIZACIONES CACHEADAS

Las actualizaciones cacheadas (cached updates) aparentemente no sólo cachean las actualizaciones a una tabla, sino que también cachean los registros leídos de la tabla. El problema es que hace las cosas más complicadas y tiene algunas desventajas... Puede encontrar información sobre actualizaciones cacheadas en la ayuda de Delphi:

    Developing Database Applications
        Working with cached updates

COMPONENTES QUE CACHEAN

Si busca en la Internet debe poder encontrar reemplazos para algunos componentes de acceso a datos (como TTable y TQuery) y algunos controles de datos (como TDBGrid, TDBLookupListBox y TDBLookupComboBox) que realizan algo de cacheo para brindar un mejor rendimiento. Estos componentes habitualmente no son freeware, pero le sugerimos que los pruebe porque bien pueden valer su costo de registración.

RANGOS DE CLAVES

Los rangos de claves son por lejos más veloces que los filtros. La razón es que al usar un filtro todos los registros de una tabla se comprueban para ver si cumplen con la condición de filtro o no, mientras que en el caso de los rangos de claves se busca el primer registro del índice dentro del rango especificado y luego se recorren secuencialmente los registros en el índice hasta llegar al final del rango, y con eso ya se tienen todos los registros deseados.

Debe aplicar rangos de claves en vez de filtros cuando sea posible para reducir la cantidad de registros a recorrer y luego si es necesario usar filtros para obtener los registros que desee (la condición de filtro sólo se comprobará para los registros del rango de claves, y no para todos los registros de la tabla). Por ejemplo, si su condición de filtro es como esta:

CustNo = X AND SaleDate > D1 AND SaleDate < D2 AND Code = Y

y tiene un índice por CustNo y SaleDate, entonces puede mejorar el rendimiento usando ese índice y aplicar un rango de claves (SetRange([X,D1], [X,D2]);) para luego usar un filtro solamente con la condición Code = Y.

PREPARAR CONSULTAS

Si usa una consulta más o menos frecuentemente puede prepararla (con el método Prepare) para hacer que la BDE la compile y la guarde compilada hasta que la libere (con el método Unprepare). Cuando una consulta está preparada se ejecuta más rápido.

COMPACTAR TABLAS

Los registros borrados ocupan espacio, y cuando el borrado de registros sucede más o menos a menudo, tarde o temprano los registros borrados pasan a ser más del 50% del total del número de registros. El espacio no utilizado no es en sí el problema, sino que se desperdicia ancho de banda de la red transfiriendo registros que no se usan. Por esta razón debe compactar las tablas removiendo los registros borrados cada cierto tiempo. El ejemplo de DbiPackTable en el archivo de ayuda muestra claramente como hacer esto.

TABLAS LOCALES Y DATASETS CLIENTES

Tal vez la mejor y más simple forma de reducir el tráfico de la red y mejorar el rendimiento sea teniendo una copia local de algunas tablas de la base de datos y usar esas copias locales para leer registros. Cuando realice una actualización (ABC), debe actualizar tanto la tabla local como la tabla en el servidor. Esto asegura que la tabla del servidor siempre esté actualizada.

El problema es que los cambios hechos por otros usuarios no serán visibles en su aplicación hasta que "refresque" las tablas locales (copiándolas nuevamente desde el servidor), y por lo tanto esta técnica sólo debe usarse con tablas para las cuales es bastante improbable que dos o más usuarios vayan a agregar o editar al mismo tiempo el mismo registro con datos diferentes.

Debe refrescar las tablas locales cada tanto: cuando Windows inicia, cuando su aplicación inicia, una vez al día, una vez a la semana, cuando el usuario presione un botón Refrescar, o cuando sea... Dependerá de la tabla, y puede juzgar caso por caso: algunas tablas pueden requerir refrescos más frecuentes que otras, y debe sacar ventaja de este hecho para no refrescar las tablas con mayor frecuencia que la necesaria.

Si usa tablas Paradox, tiene que usar una sesión diferente para las tablas locales con su propio NetFileDir conteniendo la ubicación del archivo PDOXUSRS.NET local.

Si tiene la Edición Empresarial de Delphi, puede usar Datasets Clientes (Client Datasets) para algunas de las tablas locales. Los Datasets Clientes guardan los registros en memoria (así que no debería usarlos con grandes tablas) y son muy rápidos y potentes.