Parametrizando el archivo DATABASES.CONF

1 comentario

Como ya hemos visto en artículos anteriores, el archivo DATABASES.CONF es el antiguo archivo ALIASES.CONF que ahora en Firebird 3 tiene un nuevo nombre y nuevas funcionalidades.

En ALIASES.CONF lo que hacíamos era darle un alias, apodo, nombre abreviado, o sobrenombre a las bases de datos. Hacíamos esto por dos motivos principalmente:

  1. Para usar el nombre abreviado cuando queríamos conectarnos a una Base de Datos, pues era más corto y más fácil de recordar
  2. Para dificultar el trabajo de algún intruso, pues conocer el alias no le permitía conocer la ubicación de la Base de Datos

Ejemplo de contenido del archivo ALIASES.CONF


ADMIN=D:\DATABASES\ADMINISTRATIVO.FDB

CONTA=E:\SISTEMAS\CONTABILIDAD\DATABASES\CONTA.FDB

En DATABASES.CONF podemos hacer eso mismo pero además podemos determinar el comportamiento de cada Base de Datos, de forma individual. Si lo deseas puedes renombrar a un antiguo archivo ALIASES.CONF como DATABASES.CONF y funcionará perfectamente. Pero además puedes parametrizarlo.

Los parámetros que especificamos en DATABASES.CONF pueden afectar al Servidor o al Cliente.

Parámetros de DATABASES.CONF que afectan al Servidor

  • DatabaseGrowthIncrement
  • DeadlockTimeout
  • DefaultDbCachePages
  • EventMemSize
  • FileSystemCacheThreshold
  • ExternalFileAccess
  • GCPolicy
  • LockAcquireSpins
  • LockHashSlots
  • LockMemSize
  • MaxUnflushedWrites
  • MaxUnflushedWriteTime
  • SecurityDatabase
  • SharedCache
  • SharedDatabase
  • UserManager
  • WireCrypt
  • WireCryptPlugin

Parámetros de DATABASES.CONF que afectan al Cliente

  • AuthClient
  • Providers

¿Cómo se especifican los parámetros?

A continuación del alias otorgado a una Base de Datos abrimos llave, parametrizamos, cerramos llave. Al igual que en FIREBIRD.CONF podemos comentar una línea (o parte de una línea) si escribimos en ella el símbolo de numeral (#)

Ejemplo de contenido del archivo DATABASES.CONF


# Esta es la Base de Datos que uso para registrar los datos de uso administrativo

ADMIN=D:\DATABASES\ADMINISTRATIVO.FDB

{

LockMemSize=32M     # Esta Base de Datos necesita muchísimos bloqueos

LockHashSlots=19927     # y una "hash table" suficientemente grande para ellos

}

# Esta es la Base de Datos que uso para la Contabilidad

CONTA=E:\SISTEMAS\CONTABILIDAD\DATABASES\CONTA.FDB

{

# Aquí se guardarán los nombres de los usuarios y sus contraseñas

SecurityDatabase=E:\SISTEMAS\CONTABILIDAD\DATABASES\SEGURIDAD.FDB

}

Como puedes ver, es muy sencillo. Para que el Firebird 3 sepa cual Base de Datos estás parametrizando a continuación de su alias abres llave, parametrizas, cierras llave. Y si quieres, puedes escribir comentarios, todo lo que escribas a continuación de un símbolo de numeral (#) será tratado como un comentario.

Usando macro substitución

Lo anteriormente visto es interesante, pero no es todo, aún hay más. Y es que ahora también podemos usar macro substitución en los archivos de configuración.

¿Qué es macro substitución?

Es usar unos caracteres predeterminados para referirse a algo. Es muy similar a las variables que se usan en los lenguajes de programación. La sintaxis es la siguiente:

$(nombre_de_macro)

Las macro que pueden usarse en los archivos de configuración de Firebird3

  • $(root). El directorio raíz del Firebird
  • $(install). El directorio donde Firebird está instalado. Al inicio $(root) y $(install) son los mismos, son idénticos, pero $(root) puede ser cambiado con la variable de entorno FIREBIRD, en cuyo caso será diferente de $(install)
  • $(this). El directorio donde el actual archivo de configuración está ubicado
  • $(dir_conf). El directorio donde FIREBIRD.CONF y DATABASES.CONF están ubicados
  • $(dir_secdb). El directorio donde la Base de Datos de seguridad que se usa por defecto está ubicada
  • $(dir_plugins). El directorio donde se encuentran los plug-in
  • $(dir_udf). El directorio donde se encuentran por defecto las UDF (User Defined Functions=funciones definidas por el usuario)
  • $(dir_sample). El directorio donde se encuentran los ejemplos
  • $(dir_sampleDb). El directorio donde la Base de Datos de ejemplo (EMPLOYEE.FDB) se encuentra ubicada
  • $(dir_intl). El directorio donde los módulos internacionales se encuentran ubicados
  • $(dir_msg). El directorio donde el archivo de mensajes (FIREBIRD.MSG) se encuentra ubicado. Al inicio, $(dir_msg) es idéntido a $(root) pero puede cambiarse con la variable de entorno FIREBIRD_MSG

Ejemplo del uso de macro substitución


# La Base de Datos que el Firebird trae como ejemplo

EJEMPLO=$(dir_sampleDb)\employee.fdb

{

# La Base de Datos donde se encuentran los nombres de los usuarios y sus contraseñas

SecurityDatabase=$(root)\SEGURIDAD\SEGURIDAD.FDB

}

Aquí lo que dijimos es que al conectarse a la Base de Datos cuyo alias es EJEMPLO se conecte en realidad a la Base de Datos cuyo nombre es EMPLOYEE.FDB y usando los nombres de usuarios y contraseñas que se encuentran en la Base de Datos de nombre SEGURIDAD.FDB

Conclusión:

El antiguo archivo ALIASES.CONF era muy útil para escribir menos y para dificultarles las tareas a los intrusos, el moderno archivo DATABASES.CONF además de eso también nos permite parametrizar a cada Base de Datos de forma individual, para ello a continuación del alias abrimos llave, parametrizamos, y cerramos llave. Una ayuda en nuestra tarea es la macro substitución la cual también nos permite escribir menos y además no necesitamos recordar la ubicación física de los archivos porque la macro se encarga de eso.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Un stored procedure para borrar filas de cualquier tabla

Deja un comentario

Como seguramente sabrás, lo recomendable es que todas las operaciones que realices en una tabla (INSERT, UPDATE, DELETE, SELECT) las hagas a través de stored procedures o de vistas.

¿Por qué?

Porque de esa manera el procesamiento es más rápido (el Servidor siempre es más rápido que el Cliente) y te aseguras que la operación que deseas realizar esté sintácticamente correcta (si no lo está, no podrás compilar el stored procedure o la vista).

Pero supongamos que en tu Base de Datos tienes 100 tablas. ¿Necesitas escribir un stored procedure para cada tabla para borrar las filas de esa tabla?

No, no lo necesitas, y lo mejor es que no lo hagas. Para casos así lo mejor es parametrizar es decir enviar como parámetros de entrada los datos cambiantes. Entonces, escribiendo un solo stored procedure podrás borrar las filas de cualquiera de esas tablas.

CREATE PROCEDURE SP_BORRAR_FILAS(
   tcNombreTabla VARCHAR(32),
   tcCondicion   VARCHAR(1024))
AS
   DECLARE VARIABLE lcComando VARCHAR(1024);
BEGIN

   lcComando = 'DELETE FROM ' ||
                   tcNombreTabla ||
               IIF(CHAR_LENGTH(TRIM(tcCondicion)) > 0, ' WHERE ' || '' || tcCondicion || '', '');

   EXECUTE STATEMENT :lcComando;

END;

Este stored procedure recibe dos parámetros de entrada: el nombre de la tabla y la condición para borrar filas. Y nos servirá para borrar las filas de cualquier tabla y con cualquier condición de borrado.

Ejemplo 1. Para borrar el producto cuyo identificador es 597

EXECUTE PROCEDURE SP_BORRAR_FILAS('PRODUCTOS', 'PRD_IDENTI=597');

El producto cuyo identificador es 597 será borrado (siempre y cuando no hubiera alguna restricción Foreign Key que lo impida, claro)

Ejemplo 2. Para borrar el Banco cuyo nombre es CITIBANK

EXECUTE PROCEDURE SP_BORRAR_FILAS('BANCOS', 'BAN_NOMBRE = ''CITIBANK''');

En este caso fíjate en los apóstrofos (comillas simples) que rodean a la palabra CITIBANK. Como dentro de nuestra condición queremos emplear apóstrofos (comillas simples) entonces debemos escribirlos duplicados.

Ejemplo 3. Para borrar todas las cobranzas realizadas en el mes de enero de 2014

EXECUTE PROCEDURE SP_BORRAR_FILAS('COBRANZAS', 'EXTRACT(MONTH FROM COB_FECHAX) = 1 AND EXTRACT(YEAR FROM COB_FECHAX) = 2014');

En este caso la condición es más complicada porque involucra al operador AND. Pero el stored procedure sigue funcionando perfectamente, si la condición está bien escrita entonces se borrarán las filas que se desean borrar.

Ejemplo 4. Para borrar todas las filas de una tabla

EXECUTE PROCEDURE SP_BORRAR_FILAS('TEMP', '');

Aquí, se borraron todas las filas de una tabla llamada TEMP. Como no se estableció una condición para borrar filas eso significa que se quiere borrarlas a todas.

¡¡¡MUCHO CUIDADO CON ESTO!!!

Recuerda que no poner una condición de borrado significa borrar todas las filas de la tabla.

Conclusión:

Si parametrizamos nuestros stored procedures entonces tendremos varias ventajas:

  1. Estaremos 100% seguros de que siempre funcionará bien
  2. No tendremos que perder tiempo verificando si funciona bien
  3. Escribiremos mucho menos, porque un solo stored procedure parametrizado puede hacer el mismo trabajo que muchos stored procedures no parametrizados

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21