Reglas de registros en BD Firebird

[Casimiro Noteví]

Si el usuario1 saca un listado de las nóminas sin factura.
Al mismo tiempo, el usuario2 está asociando una factura a una de esas nóminas.
El informe del usuario1 dirá que la nómina xxx no tiene factura, cuando realmente ya sí que la tiene.
Pero es que ahí no hay nada mal, ya que cuando pidió el listado, esa nómina no tenía factura.

¿Te refieres a eso?

[mjjj]

Es solo un ejemplo con facturas y nomina, en la realidad es mucho mas complejo.

Los dos usuario sacan un listado de las facturas sin nómina, el usuario1 asocia la factura 2, a la nomina 5, esta significa que si vuelvo a sacar el listado de las facturas sin nomina no aparece la factura 2. Sin embargo, si el usuario2 no vuelve a solicitar la lista, en la lista actual (la primer lista que solicitaron), aun aparece la factura 2.
En este caso, si el usuario asocia la factura 2 a la nomina x, se duplicara la factura 2 en la tabla nomina.

Espero se haya entendido mejor.

[mjjj]

Casimiro, creo que este ejemplo en particular lo puedo resolver definiendo claves unicas en Firebird, con esto evito que se duplique la factura en la tabla nomina.

Como expuse anteriormente, esto es solo un ejemplo. En la realidad si pudiese darse que una factura este en dos nomina distintas, pero en este caso la condicion sería que la sumatoria de los montos de la tabla nomina no puede ser mayor a el valor de la factura.

Las tablas estan difinidas como sigue:

Facturas:
-id_factura
-rut
-total
...

Nomina
-id_nomina
-id_factura
-monto
...

Si llevamos esto a SQL, para listar las facturas que no tienen nomina, o que su monto en monina sea menor que el monto de la fatura, lo realizo con un procedimiento almacenado.

Código SQL [-]
for select f.id_factura, rut, total from facturas into :id_factura, :rut, :total do
begin
select sum(monto) monto_total from nomina where id_factura =:id_factura
into : monto_total
suspend;
end

Donde id_factura, rut, total y monto_total son parametro de salida.

De esta forma aparecería la factura 2, si es que la sumatoria de los montos en la nomina es menor que el total de la factura.

Sin embargo, sigue el problema original, en caso de tener 2 o más usuario intentanto asociar la misma factura a una nomina, previmente con el mismo listado.

Con la clave unica no puedo resover esto.
Alguna idea?

[Casimiro Noteví]

Empezado por mjjj

Sin embargo, sigue el problema original, en caso de tener 2 o más usuario intentanto asociar la misma factura a una nomina, previmente con el mismo listado.

Tendrás que comprobar antes si ya ha sido guardada.
También puedes declarar el campo id_factura en la tabla Nomina como "unique" y así saltará una excepción porque no puede repetirse.
Porque se supone también, digo yo, que ese campo es clave foránea de la tabla facturas, ¿no?

Pero si dos personas (o más) están haciendo el mismo trabajo y con un listado "en la mano" es normal que ese listado esté obsoleto incluso antes de salir de la impresora. El programa debe controlar todas esas posibilidades.

[mjjj]

Efectivamente id_factura es clave foranea en la tabla nominas, pero no puedo hacerla unica, ya que existe la posibilidad que una factura este en mas de una nomina, siempre y cuando la sumatoria de los montos en la tabla nomina no sea superior que el total de la factura.

La ultima parte sel "listado en la mano", no entendí lo de hacerlo absoleto... como puedo hacer/controlar esto?

[Casimiro Noteví]

Lo que quería decir es que si un usuario saca un listado de nóminas (por ejemplo) y va un momento a por un café, cuando vuelva, en 5 minutos, ese listado ya puede estar obsoleto porque otro usuario ha podido hacer modificaciones en los datos, por lo que el usuario1 tiene ya un listado "obsoleto".

Creo que en tu caso no te queda otra que comprobar que no exista ya, antes de grabar.

[mjjj]

es exactamente lo que me temia... me gustaria evitar tener que realizar una consulta justo antes de insertar.

Existe alguna forma de bloquear el registro de este "tomado" por algun usuario, a lo mejor con alguna propiedad de la transaccion?

Otra alternativa, programar en la capa de la BD, quizas con el algún trigger, la idea es evitar esto en la capa del interfase con el usuario.

Como se manejan estas situaciones por regla general?

Salu2