como pasar a un stored procedure un conjunto de datos en FB 1.5

[pvizcay]

hola gente del foro, a ver si alguno se cruzo con esta duda que tengo y me puede ayudar a resolverla..!

simplificando un poco tengo dos tablas
FACTURAS(ID integer, ..., ID_TIPO integer)
TIPO_FACTURA (ID integer, DESC varchar)
de relación obvia; la tabla TIPO_FACTURA es dinámica y cambia, lo que pretendo es darle al usuario en un informe la posibilidad de filtrar los tipos de facturas que desea en un CheckListBox o algo por el estilo..

supongamos que el usuario elegió los tipos de factura con ID 3, 4, 5.. el informe se genera con un STORED PROCEDURE selecteable (porque procesa otras cosas que simplifiqué aca y además quiero desacoplarlo de la aplicación) llamado INFORME_FACT, ahora la pregunta es como le paso de manera limpia los IDs al procedure ya que:

si se los paso cada uno como un parámetro distinto tengo que suponer un número máximo de tipos de facturas (lo que por ahi en el ej. tiene sentido, pero en otras situación por el estilo no quiero limitar el número..)

y ahora suponiendo que no fuera un STORED PROCEDURE sino un SQL que se guarda en un TIBQuery normal, como lo generaría uds. SIN MODIFICAR EL TEXTO SQL...? (sino es fácil vas agregando and ID_TIPO = A, etc. por cada un al texto sql y listo)

se me ocurrió la solución puede estar creando tablas temporarias y haciendo un
SELECT * FROM FACTURAS
WHERE ID_TIPO IN (SELECT ID_TIPO FROM TEMPORARIA) ???
como se hace esto en FB de tal manera que funcione bien en multiusuario??

graciasss!!

[tefots]

hola gente del foro, a ver si alguno se cruzo con esta duda que tengo y me puede ayudar a resolverla..!

simplificando un poco tengo dos tablas
FACTURAS(ID integer, ..., ID_TIPO integer)
TIPO_FACTURA (ID integer, DESC varchar)
de relación obvia; la tabla TIPO_FACTURA es dinámica y cambia, lo que pretendo es darle al usuario en un informe la posibilidad de filtrar los tipos de facturas que desea en un CheckListBox o algo por el estilo..

supongamos que el usuario elegió los tipos de factura con ID 3, 4, 5.. el informe se genera con un STORED PROCEDURE selecteable (porque procesa otras cosas que simplifiqué aca y además quiero desacoplarlo de la aplicación) llamado INFORME_FACT, ahora la pregunta es como le paso de manera limpia los IDs al procedure ya que:

si se los paso cada uno como un parámetro distinto tengo que suponer un número máximo de tipos de facturas (lo que por ahi en el ej. tiene sentido, pero en otras situación por el estilo no quiero limitar el número..)

y ahora suponiendo que no fuera un STORED PROCEDURE sino un SQL que se guarda en un TIBQuery normal, como lo generaría uds. SIN MODIFICAR EL TEXTO SQL...? (sino es fácil vas agregando and ID_TIPO = A, etc. por cada un al texto sql y listo)

se me ocurrió la solución puede estar creando tablas temporarias y haciendo un
SELECT * FROM FACTURAS
WHERE ID_TIPO IN (SELECT ID_TIPO FROM TEMPORARIA) ???
como se hace esto en FB de tal manera que funcione bien en multiusuario??

graciasss!!

con un stored procedure no puedes hacerlo , no se le pueden pasar arrays.

lo mas facil seria crear el sql que filtre los datos agregando 'and did_tipo=a and .....'

la otra forma mas complicada , en vez de crear una tabla temporal ,puedes tener una tabla ya creada, e insertar los datos en dicha tabla antes de hacer el query. esta tabla puede tener un campo que se valla incrementando para cada usuario que inserta un conjunto de datos (puedes obtenerlo de un generador , o ir incrementandolo tu) , y luego solo hay que hacer el mismo select , pero indicando el identificador que agrupa los datos añadidos.

SELECT * FROM FACTURAS
WHERE ID_TIPO IN (SELECT ID_TIPO FROM TEMPORARIA WHERE ID_CONJUNTODATOS=X) ???

asi cada usuario inserta / borra su conjunto de datos , que luego usa para hacer el query.
eso si , luego hay que borrar para que la tablatemporal no crezca hasta el infinito.

[Crandel]

yo lo que haria seria crear un procedimiento que resuelva para un solo ID

CREATE PROCEDURE INFORME_FACT (ID integer)
.....

Luego llamas a este procedimiento deste Delphi mediante una instruccion SQL, uniendo los diferentes informes

asi:
select * from INFORME_FACT(3) union select * from INFORME_FACT(4)

Espero que te guste esta solucion :p

[pvizcay]

desde ya gracias a los dos por haber leido y contestado..
bueno estuve averiguando y pareciera que lo de la tabla temporaria es la mejor manera de ir, por lo visto FB no soporta tablas temporarias por lo que tendre que usar la variable CURRENT_TRANSACTION para asegurarme que no haya conflictos en un entorno multiusuario.. lo de los unions esta bueno pero tiene el inconveniente que tenés que modificar dinámicamente el texto de la consulta (si no entendí mal..), si son 3 IDS serían tres UNIONs y así sucesivamente.. mi idea era desacoplar completamente esto de la aplicación..

[pvizcay]

lo cual me lleva a la conclusión de que no encontré manera de manejar esto de forma limpia en firebird (lo de limpio es cuestión de gustos obviamente) pero es obvio que esta solución no escala bien.. demasiadas tablas "temporarias" sin sentido (una para cada TIPO_FACTURA, TIPO_CHEQUE, TIPO_CAMBIO, TIPO_MONEDA, etc etc.) creo yo..

[Crandel]

otra idea (no parece muy limpia pero por ahi te gusta), pasale los parametros como registros de una tabla auxiliar de la base de datos.

Luego en un procedimiento vas creando las uniones dinamicamnete de acuerdo a la cantidad de registros de la tabla.

[RONPABLO]

se me ocurre una un poco diferente y es algo como lo siguiente:


codigos = '1,3,5,12';
cadena = '';
numero=0;
j=1;
i = strlen(:codigos);
while(j<=i) do
begin
c = substr(FACTURA,j,j);
if (c between '0' and '9') then
begin
cadena = cadena || cast(:c as varchar(1));
end
else if ((c=',') or (j=i)) then
begin
numero = cast(:cadena as integer);
select * from INFORME_FACT(:numero);
cadena = '';
end;
j=j+1;
end


ya el problema es cuando se manden muchos codigos en la cadena (como tal es algo q se me ocurrio y debe de tener muchos errores pero es solo una idea)

[Lepe]

lo más fácil desde mi punto de vista es un sql del tipo:


select * from facturas where nfactura in (3, 4, 5, 6, 7);


Si te ayudas de un TStringList, puedes usar su propiedad commaText para hacer la tira 3, 4, 5, 6. Yo utilicé un Combobox para que el usuario añada las facturas, así tienes el CommaText a mano y además el usuario tiene comodidades para añadir y eliminar las facturas que quiere ver.

Este SQL puedes almacenarlo en un archivo .inc como se hace en la mayoría de paquetes, así puedes modificar el SQL en el ordenador de tu cliente sin tener que recompilar la aplicación. O incluso (y es lo que yo hago), guardas el SQL en una tabla de tu programa, así lo cargas dinámicamente.

Hay otros trucos, por ejemplo:

const sqlFacturas = 'select * from facturas where nfactura in %s';

....
query1.sql.text := format(sqlfacturas, ['(3,4,56)']);
query1.Open;

Esa constante puedes almacenarla en la BBDD, archivo .inc etc.

Inconveniente, no estará compilada nunca en FB.

Saludos

[pvizcay]

hola,
tal vez a alguno le sirva este artículo de la borland developer network al respecto aunque en vez de un SP lo trata con querys..

http://bdn.borland.com/article/32076

saludos!