Problema con select first en Firebird

[jhonny]

Acabo de darme cuenta que en una base de datos que tengo a mano, ya había hecho lo mismo con parámetros de fechas y toda la cosa, analizándolo recordé que la cuestión debe funcionarte asi:

Código SQL [-]
 
CREATE PROCEDURE REPNUM (
    E_LIMITE INTEGER = 1,
    E_INICIAL DATE,
    E_FINAL DATE)
RETURNS (
    S_PREFIJO VARCHAR(3),
    S_NUMERO VARCHAR(20),
    S_LLAMADAS INTEGER)
AS
begin
  FOR
  execute statement 'select first ' || CAST(E_limite AS CHAR(1)) ||
  ' Prefijo, Numero, count(numero) as numlla from llamadas where fecha between '''||
  :E_INICIAL||''' and '''||:E_FINAL||''' group by prefijo, numero order by prefijo, numlla desc'
  INTO :S_Prefijo, :S_Numero, :S_Llamadas DO
  suspend;
end

[[egostar]]

Perfecto, me funcionó de maravilla, solo cambié el AS CHAR(1) del E_Limite por AS INTEGER, porque pueden ser mas de 1 dígito y no sea que se les ocurra solicitar, 9, 30, 120, 1000, etc...

Como lo diria nuestro buen amigo Carlos Alberto, muchas gracias maestro.

Salud OS.

[jhonny]

Final Feliz¡¡¡ Que bueno

[[Al González]]

¿Cuál final feliz?

Tenía planeado hacer varios procedimientos con esa característica en Firebird 1.5, pero según veo ahora tendré que recurrir a la instrucción Execute Statement para que sea posible.

¿No lo hace eso un poco más lento? Hablo de unos 20 mil registros, por ejemplo.

Por otro lado, ¿cómo es que sí funciona una sentencia como la siguiente en el SQL Editor de IB Expert?

Select First :C * From Empleados

Me hace suponer que SQL Editor también utiliza Execute Statement, o bien, transforma los parámetros armando una nueva sentencia "plana" (formateo) antes de ejecutarla.

Pero no hay como estar seguros, ¿alguien puede mirar qué hace internamente el SQL Editor de IB Expert? Por favor.

Un abrazo sacado de onda.

Al González.

[[egostar]]

Hola Alberto, pues exactamente yo tengo alrrededor de 20,000 registros en esta prueba que consta de solo dos dias de información, estos reportes los sacarán por mes, así que por simple operacion matemática estamos hablando de alrrededor de los 300,000 registros al mes.

Y tienes razón, en el Editor SQL de IBExpert funciona sin problema, el tiempo a mi parecer es el mismo, a lo más 1 segundo en realizar la consulta, tanto en el SP como en el Editor SQL.

Lo que yo pretendo es que quien trabaje es la base de datos y no el lado de cliente, por eso estoy utilizando SP's.

En este aspecto, me gustaría que ustedes los que llevan tiempo con Firebird me comentaran si esto que "soñe" es lo más idóneo o mejor sería hacerlo a través de Queries en los programas como lo hacia con Paradox.

Salud OS.

[[Al González]]

¡Hola a todos!

Empezado por egostar

...quien trabaje es la base de datos y no el lado de cliente, por eso estoy utilizando SP's...es lo más idóneo o mejor sería hacerlo a través de Queries en los programas...

En la normativa de la empresa seguimos la regla de que si una operación es sobre registros, es tarea del servidor de la base de datos o cuando mucho del servidor de aplicaciones.

Todas las sentencias Select que llevan uniones horizontales (Join), uniones verticales (Union), columnas calculadas (Case, concatenaciones, operaciones matemáticas, etc.), agrupación (Group By), subconsultas (Select dentro del Select) o más de una condición en su cláusula Where, son colocadas dentro de vistas o procedimientos almacenados (en estos últimos cuando hay necesidad de parametrizar la consulta).

Es decir, los únicos Selects directos fuera de la capa de la base de datos son aquellas sentencias simples tipo "Select Campo1, Campo2, Campo3 From Tabla Where Campo4 = Valor Oder By Campo2" (normalmente son típicos "Select * From Tabla Order By Campo"). Bajo el entendido de que el programador operativo (capa cliente) o de lógica de negocios (capa intermedia) no necesariamente cuenta con el conocimiento de un especialista en bases de datos. Es el AD (administrador de datos o "DBA") quien se encarga de la programación SQL de mediana y alta complejidad a nivel de la base de datos. Además, con esto se consigue centralizar muchos procesos que no son simples, evitando que desde la base de datos crezca una enredadera de código SQL hacia las demás capas.

Con respecto al uso de Execute Statement, me inquieta un poco que tengo sentencias Select de varias decenas de líneas que ahora tendré que armar como una cadena de caracteres concatenada dentro de los procedimientos. Espero no toparme con un límite de 1024 caracteres o una cosa rara de esas que a veces pasan porque un programador de un país lejano decidió ahorrar unos cuantos bits. Hay que pensar positivo.

Un abrazo selecto.

Al González.

[jhonny]

Empezado por Al González

Con respecto al uso de Execute Statement, me inquieta un poco que tengo sentencias Select de varias decenas de líneas que ahora tendré que armar como una cadena de caracteres concatenada dentro de los procedimientos. Espero no toparme con un límite de 1024 caracteres o una cosa rara de esas que a veces pasan porque un programador de un país lejano decidió ahorrar unos cuantos bits. Hay que pensar positivo.

Si necesitas usar la primera sintaxis que describe Alex Peshkoff en http://fresh.t-systems-sfr.com/unix/...cute_statement estarías limitado a 32765 caracteres que es el tamaño máximo de un tipo VARCHAR o 32767 si decides usar un CHAR, lo que no me queda claro aun, es lo que pasaría al respecto para los casos de las sintaxis 2 y 3 que muestra dicho articulo.