Si, está claro lo que necesitas hacer.
Respecto al comentario sobre triggers de Epachsoft, hay bastante de verdad si esa tabla se maneja de manera poco ortodoxa, ordenada y documentada. Aún así se definen los triggers para caso de updates o de inserts, o de borrados, bien pensados para cada caso, y se ejecutarán siempre, sin posibilidad de olvidarse de hacer algo como actualizar el saldo. Eso garantiza la integridad de los datos, porque la regla se ejecuta aunque te olvides que existía, o aunque quieras guardar un saldo incorrecto. Y calcular el saldo nuevo ante cada operación... creo que es una regla de integridad fundamental en tu caso (ni pensemos si quedara mal en algún sitio y siguieras calculando desde allí). Aclaremos además que un trigger puede desactivarse si se desea que en una operación particular no se ejecute. Las dificultades que plantea Epachsoft pueden ser un precio adecuado a cambio de otras ventajas, que tendrás que sopesar. Personalmente, cuando una regla para una tabla es irrevocable, como que el saldo debe ser congruente con los debes y haberes... ni lo pienso, esa regla es parte de la tabla y el trigger (bien diseñado) me la garantiza. Pero es mi criterio personal.
Respecto al código de Roman:
Query.SQL.Text :=
'select haber, debe from cuenta';
está correcto, para trabajar en tu programa los datos, sólo que traes al cliente todos los registros de la tabla, y si es grande... pobre red (a menos que hablemos de tablas "de escritorio" y el BDE, en cuyo caso ni hablemos de triggers). Además, me parece que calcula un saldo mucho más rápidamente un motor en un servidor que un programa Delphi en un cliente recorriendo secuencialmente los registros de un Query, habría que probar.
Insisto que es mejor solución no guardar el saldo, a la 2da. sentencia de cálculo de Roman le agregaría un
"where fecha<TuFecha1" (supongo que hay un campo para la fecha del registro, obvio), para que el servidor te retorne el cálculo de SALDO HASTA el momento que necesites el detalle, y luego sí el
'select haber, debe from cuenta where fecha>=TuFecha1 and fecha <=TuFecha2'
para mostrar, listar, operar con los datos en detalle, pero solamente los datos que te hagan falta estrictamente. Por ejemplo, movimientos de banco entre fecha1 y fecha2. Calculas el saldo hasta fecha1 (sin ese día) y traes los registros de movimientos para ese intervalo de fechas, y ahí sí, recalculas el saldo en tu programa con el método que te pasó Roman y lo listas.
Si optas por la solución de Epachsoft y seguir con el campo saldo en tu tabla (a veces no dan ganas de romper lo que ya se hizo, no?
), es buena su idea también del almacenado. Allí, pueden serte útiles las sentencias tipo "select last 1 saldo group by saldo" (a mí no me funciona en FireBird
) o "select first 1 saldo group by saldo desc" (esa sí anda
) que obtienen ambas el último saldo, o las que se te ocurran dentro del SQL soportado por tu servidor. Sólo que ante cada cambio (insert, update o delete) deberás tener un almacenado específico (calcular para el registro agregado, o recalcular para luego del borrado o modificado, si se cambió debe o haber) que
no deberás olvidarte nunca de ejecutar (a menos, claro, que para hacer cada una de esas operaciones acudas a ese almacenado, directamente, pasándole parámetros con los datos (fecha, debe, haber...), para que los guarde y de paso recalcule el saldo como corresponde. Eso sí, si la base de datos se reparte en aplicaciones que hagan otros programadores, que lleguen a hacerte solamente el Insert y se olviden del almacenado...
No pensemos en eso.
Soy medio nuevo en esto, pero es como lo plantearía (yo, sin campo saldo)
Suerte y saludos.