16 respuestas en este tema

[poliburro]

Estoy haciendo algunas cosas en Firebird y me surge la duda.

Debo hacer un procedimiento almacenado que dado un criterio me devuelve el conjunto de filas coincidentes. ¿Cómo se hace en firebird?

Gracias.

[Delphius]

El truco está en una cláusula: SUSPEND. Ésta se emplea para ir moviéndose registro por registro y armar el conjunto de datos.
Te puedo recomendar las siguientes lecturas:
Lectura 1
Lectura 2
Lectura 3

La última está en español y explica bastante bien como entender el funcionamiento de los SP. Las dos anteriores, sobre todo la 2da, se centran más en la documentación.
Si te estás adentrando a Firebird, te recomiendo la lectura del documento Command Line, que forma parte de la documentación oficial.
No tengo un ejemplo a mano, pero en los enlaces verás unos cuantos.

Saludos,

[poliburro]

veo que en el return debe declararse la lista de campos con su tipo respectivo que serán devueltos al invocar el SP. ¿Esto es absolutamente necesario? ¿Qué sucede si quiero encapsular en un mismo sp 3 consultas distintas?

[Delphius]

veo que en el return debe declararse la lista de campos con su tipo respectivo que serán devueltos al invocar el SP. ¿Esto es absolutamente necesario? ¿Qué sucede si quiero encapsular en un mismo sp 3 consultas distintas?

Cuando se trata justamente de un SP seleccionable, debe indicarse los parámetros de salida. De modo que cada vez que se encuentra una clásula SUPEND se devuelven los datos que actualmente se hayan pasado a estos parámetros.

Así es como funciona Firebird.
Respecto a lo que comentas de encapsular 3 consultas distintas no logro entenderte bien. ¿A que te refieres? Si me das un mejor panorama podría ver en como va la mano y si es que se puede hacer. En principio nada le impide a Firebird ejecutar varios selects en un mismo SP. Mientras se haya diseñado para colocar los resultados en las variables de salida y la correcta invocación a SUSPEND no hay problema alguno.

Saludos,

[poliburro]

Respecto a lo que comentas de encapsular 3 consultas distintas no logro entenderte bien. ¿A que te refieres? Si me das un mejor panorama podría ver en como va la mano y si es que se puede hacer. En principio nada le impide a Firebird ejecutar varios selects en un mismo SP. Mientras se haya diseñado para colocar los resultados en las variables de salida y la correcta invocación a SUSPEND no hay problema alguno.

Saludos,

Con mucho gusto amigo.

Supongamos que tengo la entidad países cuyos atributos son Id, Nombre, Poblacion. Luego entonces en mi sistema tendré los siguientes requerimientos.

Devolver
1)  Id, Nombre y Población de los países registrados.
2) Dado un Id de país, el nombre correspondiente.
3) Dado un id de país la población correspondiente
4) dado un  id de país los atributos Nombre y Población.

Esta situación puedo resolverla con 4 Procedimientos almacenados dedicados cada uno a la función respectiva pero, ¿qué sucede si quiero encapsular en un solo SP las 4 consultas que devuelven campos diferentes?

[Delphius]

Solución creativa y sencilla:
Añade un parámetro de entrada más que te permita indicar el tipo de datos a devolver. Es decir, el típico parámetro de opción.
Cuando no se deba devolver un dato, simplemente se indica en el parámetro de salida algún valor que indique que no se cuenta con él, como por ejemplo 0 o un número negativo. Hasta creo incluso que es posible indicarle que sea NULL.

Saludos,

[poliburro]

Solución creativa y sencilla:
Añade un parámetro de entrada más que te permita indicar el tipo de datos a devolver. Es decir, el típico parámetro de opción.
Cuando no se deba devolver un dato, simplemente se indica en el parámetro de salida algún valor que indique que no se cuenta con él, como por ejemplo 0 o un número negativo. Hasta creo incluso que es posible indicarle que sea NULL.

Saludos,

Pero de ser así entonces me obligaría a estar siempre devolviendo el mismo número de campos generando datos tráfico innecesario ¿no cres?

[Delphius]

Pues si pero si se tiene en cuenta que esos casos son cuando ha de devolver un solo registro no me parece tan exagerada la pérdida por el tráfico.

Saludos,

[poliburro]

Pues si pero si se tiene en cuenta que esos casos son cuando ha de devolver un solo registro no me parece tan exagerada la pérdida por el tráfico.

Saludos,

Claro, aunque no me parece que sea correcto devolver campos que no tienen que ver con la sentencia que se está ejecutando. Me parece que en lo que atañe a firebird es mejor usar Sps separados.

[Rolphy Reyes]

Saludos.

Creo que la solución propuesta por Delphius es la más indicada, solo devolver nulo los campos que para determinada consulta no sean necesarios, me parece que no sería mucha carga en la red.

Además con esto te evitas el tener tantos procedimientos para darle mantenimiento en caso de un cambio de estructura.

Suerte!!

[poliburro]

Además con esto te evitas el tener tantos procedimientos para darle mantenimiento en caso de un cambio de estructura.

Suerte!!

Exacto amigo mio, esa es la idea de encapsular en un solo sp varias consultas.

[Sergio]

Si quieres que devuelva un recordset, las columnas del recordset TIENEN que estar predefindas, no hay mas manera, igual que una tabla tiene 8 columnas siempre, no hay records de 3 y otros de 8, lo que haces es dejar los otros 5 campos a null y listo, pues aqui igual.

Lo que tu pides es mas de cubos de decision y esas cosas donde las columnas se gngeran dinamicamente (una columna por año existente en los datos y esas cosas), pero eso es bastante mas avanzado y complejro, necesitas objetos externos a delphi para manejar ese tipo de cosas (busca por decisioncube por google).

[poliburro]

Si quieres que devuelva un recordset, las columnas del recordset TIENEN que estar predefindas, no hay mas manera, igual que una tabla tiene 8 columnas siempre, no hay records de 3 y otros de 8, lo que haces es dejar los otros 5 campos a null y listo, pues aqui igual.

Entiendo amigo, la idea de no tener que especificarlas me viene de otras bases de datos que no lo exigen. Por ello preguntaba si había alguna forma en Firebird de no indicarlas. Realmente mis conocimientos de firebird sin pocos.

[Fenareth]

Si quieres que devuelva un recordset, las columnas del recordset TIENEN que estar predefindas, no hay mas manera, igual que una tabla tiene 8 columnas siempre, no hay records de 3 y otros de 8, lo que haces es dejar los otros 5 campos a null y listo, pues aqui igual.

Entiendo amigo, la idea de no tener que especificarlas me viene de otras bases de datos que no lo exigen. Por ello preguntaba si había alguna forma en Firebird de no indicarlas. Realmente mis conocimientos de firebird sin pocos.

Es verdad, el hacer un select * from tabla en un stored procedure en Firebird es mucho más complejo que hacerlo en Oracle por ejemplo (que es donde tengo experiencia), donde declaras un cursor y devuelve en automático todas las columnas del select. Al final es posible hacerlo en Firebird, pero si se vuelve más tedioso...

Saludox !

[Wilson]

Supongamos que tengo la entidad países cuyos atributos son Id, Nombre, Poblacion. Luego entonces en mi sistema tendré los siguientes requerimientos.

Devolver
1)  Id, Nombre y Población de los países registrados.
2) Dado un Id de país, el nombre correspondiente.
3) Dado un id de país la población correspondiente
4) dado un  id de país los atributos Nombre y Población.

Esta situación puedo resolverla con 4 Procedimientos almacenados dedicados cada uno a la función respectiva pero, ¿qué sucede si quiero encapsular en un solo SP las 4 consultas que devuelven campos diferentes?

Para este problema que planteas no hay mayores inconvenientes para resolverlo, por supuesto que puedes encapsular todo en un mismo procedimiento, mira el código del sp:

delphi

SET TERM ^ ;
 
create or alter procedure TEST_PROCEDURE
returns (
    ID integer,
    NOMBRE varchar(10),
    POBLACION integer)
as
begin
 FOR SELECT ID, NOMBRE, POBLACION FROM PAISES INTO :id, :nombre,  :POBLACION  DO
  suspend;
end^
 
SET TERM ; ^

Ahora las llamadas:

delphi

// caso 1
SELECT * FROM TEST_PROCEDURE
 
//Caso 2
 SELECT NOMBRE FROM TEST_PROCEDURE WHERE ID = :ID
 
//Caso 3
 SELECT POBALCION FROM TEST_PROCEDURE WHERE ID = :ID
 
//Caso 4
 SELECT NOMBRE, POBALCION FROM TEST_PROCEDURE WHERE ID = :ID
 

Saludos.

[poliburro]

Para este problema que planteas no hay mayores inconvenientes para resolverlo, por supuesto que puedes encapsular todo en un mismo procedimiento, mira el código del sp:

Excelente ejemplo. Muchas gracias por el código amigo.

[Delphius]

Supongamos que tengo la entidad países cuyos atributos son Id, Nombre, Poblacion. Luego entonces en mi sistema tendré los siguientes requerimientos.

Devolver
1)  Id, Nombre y Población de los países registrados.
2) Dado un Id de país, el nombre correspondiente.
3) Dado un id de país la población correspondiente
4) dado un  id de país los atributos Nombre y Población.

Esta situación puedo resolverla con 4 Procedimientos almacenados dedicados cada uno a la función respectiva pero, ¿qué sucede si quiero encapsular en un solo SP las 4 consultas que devuelven campos diferentes?

Para este problema que planteas no hay mayores inconvenientes para resolverlo, por supuesto que puedes encapsular todo en un mismo procedimiento, mira el código del sp:

delphi

SET TERM ^ ;
 
create or alter procedure TEST_PROCEDURE
returns (
    ID integer,
    NOMBRE varchar(10),
    POBLACION integer)
as
begin
 FOR SELECT ID, NOMBRE, POBLACION FROM PAISES INTO :id, :nombre,  :POBLACION  DO
  suspend;
end^
 
SET TERM ; ^

Ahora las llamadas:

delphi

// caso 1
SELECT * FROM TEST_PROCEDURE
 
//Caso 2
 SELECT NOMBRE FROM TEST_PROCEDURE WHERE ID = :ID
 
//Caso 3
 SELECT POBALCION FROM TEST_PROCEDURE WHERE ID = :ID
 
//Caso 4
 SELECT NOMBRE, POBALCION FROM TEST_PROCEDURE WHERE ID = :ID
 

Saludos.

¿Podés creerlo que se me escapaba ese "pequeño" detalle? Llevo tanto tiempo alejado de la programación que ya se me olvidada que un SP seleccionable actúa como una tabla normal y es posible indicarle que campos extraer.

Saludos,