[SOLUCIONADO] Consulta condicional

[bandolera]

Tengo una tabla que tiene los campos:

Código PHP:

  codigo, cargo, abono  
   

los cuales se repiten.
Quiero seleccionar los saldos por código.
Hice esto:

Código MySQL:

SELECT codigo, SUM( cargo ) , SUM( abono ) , SUM( cargo ) - SUM( abono ) 
FROM sc_ctacte
GROUP BY cod_stud
 

Entonces me muestra cada código con el saldo ordenado por código.
Pero yo no quiero que me muestre los que tienen saldo cero (0).
Como le hago?

[leonardo_josue]

Hola Bandolera:

cuando necesitas filtrar una consulta de acuerdo al resultado de una agrupación, puedes utilizar la cláusula HAVING, sería más o menos así:

Código MySQL:

SELECT codigo, SUM( cargo ) , SUM( abono ) , SUM( cargo ) - SUM( abono )  
FROM sc_ctacte 
GROUP BY cod_stud
HAVING SUM( cargo ) - SUM( abono ) = 0
 

Haz la prueba y nos comentas.

Saludos
Leo

[bandolera]

Iniciado por leonardo_josue

Hola Bandolera:

cuando necesitas filtrar una consulta de acuerdo al resultado de una agrupación, puedes utilizar la cláusula HAVING, sería más o menos así:

Código MySQL:

SELECT codigo, SUM( cargo ) , SUM( abono ) , SUM( cargo ) - SUM( abono )  
FROM sc_ctacte 
GROUP BY cod_stud
HAVING SUM( cargo ) - SUM( abono ) = 0
 

Haz la prueba y nos comentas.

Saludos
Leo

Sí, era lo que necesitaba. Gracias!!!
Pero por qué me sale el mensaje: This table does not contain a unique column. Grid edit, checkbox, Edit, Copy and Delete features are not available.
Exactamente qué significa eso??

[gnzsoloyo]

Que tienes una tabla basura, como se dice en la jerga de BBDD.

Esa tabla carece de PRIMARY KEY, o al menos una clave única (UNIQUE), pro lo cual puede contener ingentes cantidades de datos inconsistentes.
Está prohibido en el modelo relacional crear tablas que no tengan PK o al menos una clave UNIQUE. Los motores de BBDD las soportan, pero te advierten del error, como en ese caso.

[bandolera]

Iniciado por gnzsoloyo

Que tienes una tabla basura, como se dice en la jerga de BBDD.

Esa tabla carece de PRIMARY KEY, o al menos una clave única (UNIQUE), pro lo cual puede contener ingentes cantidades de datos inconsistentes.
Está prohibido en el modelo relacional crear tablas que no tengan PK o al menos una clave UNIQUE. Los motores de BBDD las soportan, pero te advierten del error, como en ese caso.

Pero mi tabla si tiene PK.

Código PHP:

  id, fecha, codigo, cargo, abono  
   

El PK es el ID. Pues el código se repite porque hay fechas diferentes.
Es un estado de cuenta corriente.
Y el select que estoy haciendo solo toma el código que no es el PK. Tal vez sea por eso que sale ese mensaje. Cierto?

[gnzsoloyo]

¿Estás intentando editar el resultado de la consulta?

[bandolera]

Iniciado por gnzsoloyo

¿Estás intentando editar el resultado de la consulta?

Quiero poner el resultado del select en una pantalla que me muestre el codigo, cargo, abono y saldo y si se quiere ver el historial quiero darle un click para ver los registros que lo generan.

[gnzsoloyo]

Quiero poner el resultado del select en una pantalla que me muestre el codigo, cargo, abono y saldo y si se quiere ver el historial quiero darle un click para ver los registros que lo generan

Bueno, ese es el tema. Eso no existe...

Cuando ejecutas una consulta de agregación, todas las lineas que se usaron no existen, sólo se leyeron pero no se conservaron en memoria. Solo existe el resultado obtenido.
Esto implica que si quieres recuperar las lineas que generaron el dato tienes que obtener de la selección del dato en pantalla los valores necesarios para realizar una segunda consulta, segmentando los registros para obtener los que se agruparon en ese registro visual.

¿Se entiende?

La base no conserva un registro de lo que leyó. Tienes que generar una consulta específica, o los datos no los verás.

[bandolera]

Iniciado por gnzsoloyo

Bueno, ese es el tema. Eso no existe...

Cuando ejecutas una consulta de agregación, todas las lineas que se usaron no existen, sólo se leyeron pero no se conservaron en memoria. Solo existe el resultado obtenido.
Esto implica que si quieres recuperar las lineas que generaron el dato tienes que obtener de la selección del dato en pantalla los valores necesarios para realizar una segunda consulta, segmentando los registros para obtener los que se agruparon en ese registro visual.

¿Se entiende?

La base no conserva un registro de lo que leyó. Tienes que generar una consulta específica, o los datos no los verás.

hhmm.... y cómo puedo lograr lo que quiero? Crear una tabla con ese select? o alimentar con los saldos una tabla SALDO que tenga PK el codigo?

[gnzsoloyo]

No compliques las cosas. No se crean tablas por necesidades de vistas o de mostrar datos con agregación. Se crean para dar persistencia a la información, y una de las reglas es que NUNCA se almacenan datos calculables.
Esto quiere decir que no tiene ningún sentido ni utilidad crear tablas de resumen, donde guardes datos acumulados, porque el tiempo de mantener la consistencia de esos datos es superior al que usarías consultándolos neuvamente desde las tablas base.

Lo que tienes que hacer es lo que escribo: Programar bien, de modo que cuando quieras un detalle de alguno de los conceptos obtenidos por agregación, la aplicación tome los datos necesarios y envie a hacer una consulta específica de ese rango.
Es lo que hacen todas las aplicaciones que conoces en la web o las empresarias.
No hay nada nuevo bajo el sol en este sentido. Lo que debes que hacer es armarte de paciencia y diseñar bien la lógica necesaria para que tu programa haga exactamente ESO.

El 99% del problema lo debes resolver programaticamente. La base te devolverá lo que le pidas.

Te doy un sólo tip:
En esa vista, cuando hayas mostrado los datos en la tabla visual, al hacer click sobre un registro ¿qué datos consideras que puedes obtener que te permitan realizar una consulta de detalle?
Los tienes delante de tus ojos. No hay ningún secreto... Es solo observación: Tienes el código, y tienes el saldo... tienes todo lo necesario para obtener el detalle de la consulta.

[Libras]

Iniciado por gnzsoloyo

No compliques las cosas. No se crean tablas por necesidades de vistas o de mostrar datos con agregación. Se crean para dar persistencia a la información, y una de las reglas es que NUNCA se almacenan datos calculables.
Esto quiere decir que no tiene ningún sentido ni utilidad crear tablas de resumen, donde guardes datos acumulados, porque el tiempo de mantener la consistencia de esos datos es superior al que usarías consultándolos neuvamente desde las tablas base.

Lo que tienes que hacer es lo que escribo: Programar bien, de modo que cuando quieras un detalle de alguno de los conceptos obtenidos por agregación, la aplicación tome los datos necesarios y envie a hacer una consulta específica de ese rango.
Es lo que hacen todas las aplicaciones que conoces en la web o las empresarias.
No hay nada nuevo bajo el sol en este sentido. Lo que debes que hacer es armarte de paciencia y diseñar bien la lógica necesaria para que tu programa haga exactamente ESO.

El 99% del problema lo debes resolver programaticamente. La base te devolverá lo que le pidas.

Te doy un sólo tip:
En esa vista, cuando hayas mostrado los datos en la tabla visual, al hacer click sobre un registro ¿qué datos consideras que puedes obtener que te permitan realizar una consulta de detalle?
Los tienes delante de tus ojos. No hay ningún secreto... Es solo observación: Tienes el código, y tienes el saldo... tienes todo lo necesario para obtener el detalle de la consulta.

Solo puedo decir Maestro