Problema con group by

[[fjcg02]]

Hola,
te da los mismos registros esto

Código SQL [-]
SELECT "idProducto" FROM "Inventario"
  WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN
  GROUP BY "idEmpresa","idAlmacen", "idProducto"

que esto ?

Código SQL [-]
SELECT DISTINCT "idProducto" FROM "Inventario"
  WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN

Es que esa query que haces es muy rara...

Yo me inclino por algún registro que tenga algún dato nulo.

Prueba y nos dices.

Saludos

[Toni]

Hola! Gracias a ambos por las rapidas respuestas.

Casimiro, esto solo le sucede al cliente con sus datos yo no he logrado reproducir el error o problema, pero con todos los datos que me ha guardado y el propio registro del programa es la unica conclusion que llego. Entiendo lo que dices y tienes toda la razon, pero tampoco tengo un caso en el que se reproduzca el fallo. De hecho he reproducido todas las acciones que fallaron en casa del cliente y no se reproduce el fallo.

fjcg02, Ciertamente una de las cosas que he revisado son lo datos, posibles nulls o algun dato que en apariencia es similar y despues no lo es (con espacios en blanco o cosas similares) pero todo parece estar correcto. Ademas por eso mismo he utilizado una copia anterior de la base de datos para realizar las pruebas.

Código SQL [-]

SELECT "idProducto" FROM "Inventario"
  WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN
  GROUP BY "idEmpresa","idAlmacen", "idProducto"

Que es lo que ves raro de la SQL que utilizo? Los campos por los que agrupa son parte de la llave primaria, lo que si es cierto que se al filtrar por empresa y almacén podria obviarlos en la clausula group by, pero tampoco creo que esto este mal..

PD: El sistema es un W2K3 server con Firebird 2.5.2

[[fjcg02]]

Empezado por Toni

Que es lo que ves raro de la SQL que utilizo? Los campos por los que agrupa son parte de la llave primaria, lo que si es cierto que se al filtrar por empresa y almacén podria obviarlos en la clausula group by, pero tampoco creo que esto este mal..

Hola de nuevo,
no digo que esté mal la query, pero me sorprende un poco.
Yo cuando agrupo, es porque lo necesito. En este caso no es necesario. A veces una agrupación puede variar los resultados.
Yo por definición, en las cosultas agrupadas siempre pongo los campos por los que va agrupada, así puedo comprobar el dato ( cuantas veces hemos dado por supuestas ciertas condiciones que luego hemos visto que no son correctas).

Lo dicho, no es que esté mal, sino que como no sacas los datos por los que agrupa, simplemente me ha parecido "extraño".

Por otro lado, no me has contestado... las dos querys te dan los mismos resultados ? La última que has puesto no es igual que la primera.

A ver si puedes descubrir este "asunto". Me tiene intrigado.

Un saludo

[Toni]

Hola!

En el ejemplo que he puesto he intentado sintetizar la raiz del problema, cuando realizado un agrupación es porque si que es necesario. Pero es por no complicar mas el asunto que lo he resumido. He probado las dos querys en el servidor del cliente y me dan extamente el mismo resultado. He realizado el mismo proceso que ha realizado el cliente recuperando sus datos y no consigo reproducirlo, pero como comente tengo constancia de que algo no esta funcionando como debe.. Todo el problema esta en ese procedimiento y se ejecuta en una unica transacción. He quedado con el cliente para que vuelvan a realizar el proceso de inventario y estare yo para validar paso a paso. Me he preparado unas consultas para comprobar que el proceso funciona correctamente. Ya os ire contando.. si se os ocurre alguna cosa soy todo oidos.

La verdad es que el primer sorprendido soy yo, llevo muchos años con Firebird y estoy encantado con esta base de datos. Por ese motivo en lo ultimo que se me ocurre pensar es en un fallo del mismo.

[Casimiro Noteví]

Empezado por Toni

Por ese motivo en lo ultimo que se me ocurre pensar es en un fallo del mismo.

Apuesto mi colección de comics de superman a que no es fallo de él.

[[fjcg02]]

Empezado por Toni

...he intentado sintetizar la raiz del problema, cuando realizado un agrupación es porque si que es necesario. Pero es por no complicar mas el asunto que lo he resumido....

Ahora está claro, es normal.

Empezado por Toni

La verdad es que el primer sorprendido soy yo, llevo muchos años con Firebird y estoy encantado con esta base de datos. Por ese motivo en lo ultimo que se me ocurre pensar es en un fallo del mismo.

Coincido con Casimiro...

A ver si puedes dar con el problema.

Suerte y un saludo

[pacopenin]

Empezado por Toni

Hola! Gracias a ambos por las rapidas respuestas.


Código SQL [-] SELECT "idProducto" FROM "Inventario" WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN GROUP BY "idEmpresa","idAlmacen", "idProducto"



PD: El sistema es un W2K3 server con Firebird 2.5.2

No acabo de entender el sentido de esa select : devolver codigos de registro agrupados por dos criterios pero sin que salgan esos criterios.

¿De qué sirve que salgan los códigos de producto sin saber de que empresa y almacén es cada una?


000001
000001
000001
000002
000002
000002
000002
000002
000003
000003
000004
....


Nunca he utilizado clausulas GROUP BY que incluyan más campos que la propia select, la verdad.

EDITO . No había caido en los parámetros. Pero, si pasas esos parámentros, ¿para que agrupas? El sentido de las agrupaciones es aplicar operaciones estadísticas : contar, sumar, promediar, etc..

[Toni]

Digamos que se podrian haber obviado.. los pongo por inercia, ya que son la clave principal del la tabla y puede que ayuden a utilizar mejor el plan adecuado, pero comoya dije se podrian obviar.. De todas formas no he conseguido reproducir ni una sola vez el problema. Y el resultado de esa select y el de la otra que comentaba fjcg02 me han dado el mismo resultado.

[pacopenin]

Pues el único criterio que afecta a la selección de un registro de la tabla "inventario" es que sea de una empresa concreta y un almacén concreto. No creo que el group by afecte (aunque yo probaría a quitarlo, lo que no hace nada, mejor que no estorbe ni ocupe) . En mi humilde opinión, o fallan los parámetros pasados o en problema está en los procedimientos siguientes. Una select de un id y un where con dos parámentros no hay nada más que pueda impedir que un registro concreto sea seleccionado que esos parámetros. Aunque si has resumido para la explicación puede ser que la select no sea tan sencilla, claro. No se me ocurre nada más para tratar de ayudar. Suerte.

[Toni]

Despues de realizar unas pruebas en casa del cliente con los procesos que me estan dan el problema, he podido ver que el problema no viene del 'group by' como me parecia.. la verdad es que el misterio se ha trasladado hacia la inicialización de los datos de la tabla que realizo el 'group by'. Dicha tabla la inicializo con todos los registros de la tabla 'stock' con una unica sentencia 'insert into select' por lo que daba por hecho que estaban todos los registros en la tabla y por eso fallaba el 'group by'. Pero es que era lo logico pensar esto, ya que en esa tabla se realiza la inserción masiva de registros y no hay ningun proceso de eliminación de registros en dicha tabla desde el programa. Ademas he realizado multiples pruebas de inicializar la tabla y siempre coinciden el numero de registros..

Misterio, misterio.....