Actualización números de factura

[kinobi]

Hola,

la función de los generadores es justamente la inversa: garantizan que no se producirán duplicados de claves, y en consecuencia que no habrá "Key violations", pero no garantizan una secuencia correlativa.

En pocas palabras, en un entorno multi-transacción (InterBase) es imposible conseguir una secuencia correlativa de enteros y que además no se puedan producir errores de claves duplicadas.

Saludos.

[Chaja]

Hola:
Me enganche en este hilo buscando otra coas y bueno.
Mira yo tenia el mismo problema. Por lo pronto yo no uso como clave primaria el mismo numero del comprobante, si no que uso un id interno, que lo tomo de un generador, tanto en la cabecera como en las lineas. Ese Id que es un Integer lo uso como PK. Los numero de comprobantes lo tomo de una tabla que tiene (igual que vos) de un campo de numero el cual leo y le sumo uno. Cuando dos puesto de trabajo hacen el mismo tipo de comprobante, no me afecta ya que los dos tiene un id diferente y no hay conflictos, pero si van a tener el mismo numero de comprobante. Entonces en el momento de hacer un commit en la base de datos en el BeforePost hago una consulta de la tabla de comprobantes donde esta el numero de comprobante, si el numero difiere en el numero mas uno listo lo gravo pero si el otro gravo antes que yo la diferencia va ser menor ya que cuando gravo el comprobante actualizo el campo de numero con el ultimo ingresado. re-actualizo el numero de factura y vuelvo actualizar el numero de comprobante en la tabla de comprobantes. y dejo que grave.
No se si me entendistes.. cualquier cosa [email protected]

chau

[jam]

Chaja tiene razón, el nº de factura no debe ser la clave primaria, y para generarlo se pueden utilizar varios métodos, yo el que uso es mediante un disparador que se activa al guardar los datos en el servidor, (cuando se ha confirmado la inserción del registro), luego hago un refresh y recupero el nº de factura.
Antes almacenaba el último número en una tabla, pero ahora lo que hago es obtenerlo con la consulta:

select max(n_factura)+1 from facturas

No se si el maestro Kinobi tiene un método mejor.

[marcoszorrilla]

Pues yo creo que el número de factura ha de ser clave única, otra cosa es como obtener ese número único en el momento de la grabación.

Yo utilizo una tabla auxiliar y en el evento beforeInsert:
1º.- Pongo en edición el último número que es un campo de esta tabla auxiliar,, con lo cual garantizo que no pueda acceder nadie a él en ese momento.
2º.- Le sumo 1 y lo libero

Ahora ya tengo un número único para la factura que se está grabando, la consulta le veo un problema, si se da la casualidad que dos puestos acceden a hacer la consulta al mismo tiempo obtendrán el mismo número de factura.

Un Saludo.

[kinobi]

Hola,

Empezado por marcoszorrilla

Pues yo creo que el número de factura ha de ser clave única,...

Estoy de acuerdo, no consigo recordar ningún caso en que una factura (entendido como un documento con valor contable) pueda tener un identificador duplicado. Ahora bien, también estoy en la tesis que se comenta anteriormente: el identificador (o número) de factura debe ser único (clave alternativa), pero no clave primaria. Las claves primarias no deberían tener valor semántico en el modelo de datos.

Saludos.

[marcoszorrilla]

De acuerdo, en donde digo clave única = Indexado sin duplicados en algunos contextos, porque como muy bien apuntas el número de factura debe de ser único.

Un Saludo.

[jam]

Estoy de acuerdo con Kinobi, se me olvidó comentar que tengo un índice secundario asociado al nº de factura y si se intenta insertar un valor que ya existe se produce una excepción. Mi programa la captura y vuelve a intentarlo hasta que no se de ningun error.