Problema con group by

[Toni]

Buenas tardes!

Tengo un problema en una aplicación de inventarios que al validar el inventario hay algunos registros que no los procesa. Tengo la constancia que dichos registros estan, pero el procedimiento almacenado que procesa todo la tabla en cuestión parece saltarse algun que otro registro. De unos 1.000 registros me han reportado unos 3 fallos 'misteriosos'. Como son unos procesos que funcionan hace mucho tiempo y nunca dieron problemas, lo primero que pienso es que han hecho algo mal. Por este motivo les hice que me guardasen unos listados con la información de las tablas implicadas y asi poder buscar el problema.

Resumiendo un poco, ya he descartado el fallo del usuario, tengo constancia de que existian unos registros de inventario pero al realizar el proceso de validacion se ha vuelto a dejar por procesar unos registros. Todo esto deja constancia en otra tabla y esta evidencia que no se procesaron dichos registros.

Concluyendo, tengo localizado el problema en un procedimiento almacenado en el bucle principal que hace una agrupación por producto y la clave principal es ("idEmpresa","idAlmacen", "idProducto")



FOR SELECT "idProducto" FROM "Inventario"
WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN
GROUP BY "idEmpresa","idAlmacen", "idProducto"
INTO :V_PRODUCTO DO
BEGIN

REGISTRO_PRODUCTO_PROCESADO;

AJUSTE_STOCKS_PRODUCTO;

END



Pues parece ser que por alguna razon esta select agrupada no retorna algun registro. Antes de decir tal cosa me he asegurado en averiguar que el dato que no 'procesa' estaba. He intentado reproducir el problema haciendo la select desde el EMS Manager, haciendo la misma operativa que han realizado los operacios (ya que tengo las copias de seguridad del antes y despues) y no consigo reproducirlo.

Este procedimiento que comento deja constancia en otra tabla de cada registro que procesa y no hay nada sobre estos registros que como ya dije si estaban, tanto en el listado justo antes de hacer el proceso como en la copia de la base de datos anterior.

La pregunta es: en el supuesto de que tenga razon y falle esta simple select de agrupación que creeis que podria ser?

Os pongo un ejemplo de que me refiero, por ejemplo podria ser como hace Firebird con comparaciones cuando hay datos a NULL, que no los tiene en consideración y el resultado parece extraño cuando no se sabe como actua.

Se os ha dado algun caso similar?

[Casimiro Notevi]

Si pudiéramos contar con esa tabla y algunos registros de prueba :rolleyes:

[fjcg02]

Hola,
te da los mismos registros esto
SELECT "idProducto" FROM "Inventario"
WHERE "idEmpresa"=:P_EMPRESA and "idAlmacen"=:P_ALMACEN
GROUP BY "idEmpresa","idAlmacen", "idProducto"

que esto ?
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.



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]

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. :D

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 Notevi]

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]

...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.


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]

Hola! Gracias a ambos por las rapidas respuestas.


Código SQL [-] (http://www.clubdelphi.com/foros/#) 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.. :confused:

Misterio, misterio.....