Variables Globales
 

Hola a todos he realizado esta misma pregunta solo que años atrás cuando solo había Firebird 1.5.
En ese entonces solo quería poder definir en alguna parte de la base de datos una especie de por así llamarles Etiquetas las cuales pudieran utilizarse en cualquier código o procedimiento almacenado.

Ejemplo:

#define NUM_PI = 3.1415. (Similar a lenguaje C++ solo como Ejemplo)


Después utilizarlos en algún código de algún o todos los procedimientos:

FOR SELECT...
BEGIN
IF(:VARX=NUM_PI)
BEIGN
END
END

Según entendía esto o algo similar se podría utilizar en versiones futuras como la actual 2.5 pero no lo encuentro hasta el momento. Alguien sabe de alguna solución a este tipo de requerimiento.

Por su ayuda muchas gracias.

Hola Abel.

Hasta donde sé Firebird no contempla variables globales.

Si usas una versión anterior a la 2.0 podés usar UDF's o crearte un procedimiento:

Código SQL [-]
CREATE PROCEDURE NUM_PI RETURNS(PI DOUBLE PRECISION) 
AS
BEGIN
  PI = 3.141592654;
END

A partir de la versión 2.0 tenes la opción de usar RDB$SET_CONTEXT y RDB$GET_CONTEXT:

Código SQL [-]
CREATE PROCEDURE NUM_PI
AS
BEGIN
  RDB$SET_CONTEXT('USER_TRANSACTION', 'NUM_PI', 3.141592654);
END;

Luego de ejecutar el procedimiento,

Código SQL [-]
  EXECUTE PROCEDURE NUM_PI;

podés usarlo hasta en un SELECT, como por ejemplo:

Código SQL [-]
SELECT RDB$GET_CONTEXT('USER_TRANSACTION','NUM_PI') FROM RDB$DATABASE;

Un saludo.

Muchas Gracias por tu amable respuesta. Ahora entiendo como seria el uso a partir de la versión 2.0.
Me imagino que el procedimiento que marcas como "CREATE PROCEDURE NUM_PI" se ejecutaria solo una vez para grabar el valor en la base de datos actual.
y despues de ahi solo haces uso de este valor a través de los dos metodos que citas.
Solamente validos para la base de datos donde ejecutaste el primer procedimiento.

Hola Abel.

Mas o menos si... Una vez creado, el procedimiento queda en la base de datos en forma definitiva. Pero lamentablemente para lo que buscas hacer, el nombre de espacio USER_TRANSACTION persiste lo que dura la transacción activa y USER_SESION tiene una vida igual a la duración de la sesión actual, luego de la cuál ambos se inicializan. Por lo que deberías llamar al procedimiento NUM_PI para registrar el valor nuevamente.

Creo que la solución más persistente es almacenar el/los valores que van a usarse como constantes en una tabla.

Un saludo.

Acompaño la opinión de ecfisa, me inclinaría a pensar más en una tabla CONSTANTES y extraer de ésta el valor.

Aunque, si la idea es poder utilizar de éstas en otras bases de datos y entornos me parece lo más lógico, limpio, y natural definir UDFs... Es más no me extrañaría que ya alguien haya implementado una biblioteca llena de UDFs que implementen (o estimen) estas constantes; al menos la más comunes y empleadas en cálculos y operaciones de ingeniería. Con buscar no se pierde nada ;)

Ups definitivo, creo que es mejor optar por una tabla de Constantes. Dado lo que me explican.
lamentable mente mi idea va un poco más orientada a soluciones que se podrían aplica a este tipo de códigos:

KIND: Columna que Identifica el tipo de Registro.

IF ( KIND in (213 /*TIPO DE REG X*/,
206 /*TIPO DE REG Y*/,
......,
......,
215/*TIPO DE REG Z*/,
)
)
THEN
BEGIN
END

Donde por ejemplo en este pedazo de código el Numero 213 me identifica un tipo en específico de Registro y para no estar marcando cada vez
" 213/*TIPO DE REG XXXX*/ " seria usar un constante con nombre y valor definido en alguna parte de la base de datos facil de cambiar o alterar sin tener que buscar en toda la BD donde se uso por ejemplo el numero 213.

Pues esa era la cuestión.

Pero pues entiendo que esto no es posible hasta el momento por lo tanto a esperar....


Muchas gracias por el Apoyo compañeros.