Reglas de registros en BD Firebird

[mjjj]

Amigos de foro, después de ya haber desarrollado varias aplicaciones, las cuales cada vez se conectan mas usuarios, me ha surguido una duda.

Utilizo Firebird 2.5 y Delphi 2010.
Imaginemos la siguiente situación, un usuario realiza una consulta a la BD, la cual tiene implicita condiciones para evitar problemas, por ejemplo: todas las facturas tal que no estén en nómina, sería algo así:

Código SQL [-]
select f.* from facturas f left join nomina n on f.id_factura = n.id_factura where n.id_factura is null

Ahora pensemos que un segundo usuario realiza la misma consulta, previamente a que el primer usuario inserte, modifique o elimine algún registro que cambie el resultado de la consulta. Es decir, ambos usuario tienen los mismo resultados (en este caso facturas) que cumplen con la condiciones de no estar en alguna nomina.

Seguido a esto el segundo usuario asocia cierta factura (por ejemplo la numero 3) a una nomina.
Si es que el primer usuario NO refresca la consulta, e intenta asociar la misma factura 3 a una nómina tendré una duplicidad y posterior problemas con esto.

No puedo resolver esto, sin tener que refrescar la cunsulta antes de insertar, modificar o eliminar el registro?

Se puede programar condiciones (reglas) en el mismo motor de BD?
Como se hace esto?
Algun link de donde aprender?

Espero me puedan ayudar.
Gracias

[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?