[SOLUCIONADO] Obtener siguiente Indice Incremental

[dimas18]

Buen dia amigos.

Estoy creando una aplicacion para facturar,pero me gustaria podeer crearla para poderla usar en red, la cuestion es obtener el siguiente indice incremental y mantenerlo para que cuando alguien consulte otro indice para insertar no obtengan el que tengo seleccionado en la primera maquina.

Normalmente lo hacia obteniendo el numero mayor y sumandole 1.
Luego lo modifique y es el que uso actualmente es que obtengo el siguiente valorincremental del indice y una ves obtenido modifico la columna y le sumo 1 al valor incremental para que cuando otra maquina consulte el siguiente incremental no le sale el que tengo en la maquina 1, no se si me explico, que el codigo seria asi.

Código MySQL:

SELECT `auto_increment` FROM INFORMATION_SCHEMA.TABLES WHERE table_name = 'factura'
 

Editado: Código de programación no permitido en foros de Bases de Datos.
Leer las normas del foro, por favor.

y el code incremental que uso es este

Código MySQL:

ALTER TABLE "+t+" AUTO_INCREMENT = "+v
 

Cabe destacar que laaplicacion es en JAVA.
Actualmente me funciona, pero el problema es que si el usuario abre varias veces algun form donde tengo aplicado este codigo el valor incremental sube y sube inecesariamente.
Ya loque me gustariarealmente es: si abro un form obtenga el sig valor incremental y que lo bloquee solo para el, que si no se llena o se inserta nada y se cierre el form lo suelte y quede disponible para otra consulta a menos que cuando este bloqueado otra pc inserte registros ahi si que se inserte en el sig incremento despues del bloqueo de la maquina 1.
Espero que me entienda.

Gracias

[gnzsoloyo]

En realidad lo que tienes no es un problema de BBDD, sino un problema de diseño de sistemas. En un sistema de facturación que va a funcionar en red es absolutamente imposible hacer una reserva de autoincremental sin generar este tipo de inconveniente, y otros mucho mayores.
Todo debido al principio mas sencillo de todo sistema concurrente: La coexistencia de N transacciones simultáneas.

En realidad, siendo que forzosamente la facturación es el cierre de toda operación, y esta debe ser consistente, y no puede crearse en una forma que la numeración presente discrepancias con la hora de creación del comprobante, esta se debe ejecutar como un proceso atómico, y por ende no puede tomarse el número de factura previamente. Debe siempre crearse en el momento de la emisión (requisitos legales en todas partes del mundo).
Los sistemas concurrentes en realidad solucionan parte del inconveniente creando un estado intermedio de la compra, en una tabla transaccional que luego relacionan con la de facturación, pero sólo a los efectos de la consistencia de datos.
Esta tabla transaccional solo debe ser consistente consigo misma, por lo que el orden numérico de su identificador es irrelevante.
¿Qué quiero decir con todo esto?
Bueno, simplemente creas una tabla de, digamos, "ordenDePedido", donde vas a cumulando todos los detalles necesarios para la emisión de la factura, y sólo al confirmar toda la operación tomas esos mismos datos y los vuelcas en la factura, en un sólo ciclo de proceso, recuperando en el acto el numero de factura que se genera .
¿Se entiende?
NUNCA usas una tabla de facturas como tabla de proceso previo. JAMÁS.
Usas siempre tablas intermedias y la ejecución de facturación es un proceso atómico de cierre final.

Una factura nunca debe tener procesos posteriores que modifiquen datos una vez emitido su identificador. Toda modificación de la operación asentada en una factura, siempre generará nuevos documentos a registrar en otras tablas, pero la factura en si se cierra junto con la generación de su identificador, y no se modifica.
Respecto a la consistencia tiempo-numero de factura, me refiero a que si si tienes dos facturas con números consecutivos, en todas las legislaciones que yo conozco, la factura de numero mayor siempre debe tener una fecha y hora posteriores, y eso puede no cumplirse en tu sistema (dependería de cuanto tarde la segunda transacción), con lo que existe margen para que la facturación sea legalmente considerada fraudulenta, si las horas de registración son inversas a la numeración. ¿Queda claro?

¿Se entiende la idea?

[dimas18]

Con lo de las horas quede comprendido.
con lo de los codigos a ver si entendi, es que no debo de tomar el numero incremental, si no que debo de dejar que se autoincremente al momento que se ingrese la factura, es asi? y si es asi comprendi que puede haber un error con la fecha y la hora de la creacion del documento, ya que si llamo primero el form, y otro en red llama el mismo form con el valor incremental siguiente, y hace el proceso primero que mi, y yo un par de horas despues quedaria con una fecha menor adelante de una mayor.

Si fuera asi,como harian los otros grandes sistemas de facturacion para obtener elcodigo primero alabrir el formulario de facturacion.

Iniciado por gnzsoloyo

En realidad lo que tienes no es un problema de BBDD, sino un problema de diseño de sistemas. En un sistema de facturación que va a funcionar en red es absolutamente imposible hacer una reserva de autoincremental sin generar este tipo de inconveniente, y otros mucho mayores.
Todo debido al principio mas sencillo de todo sistema concurrente: La coexistencia de N transacciones simultáneas.

En realidad, siendo que forzosamente la facturación es el cierre de toda operación, y esta debe ser consistente, y no puede crearse en una forma que la numeración presente discrepancias con la hora de creación del comprobante, esta se debe ejecutar como un proceso atómico, y por ende no puede tomarse el número de factura previamente. Debe siempre crearse en el momento de la emisión (requisitos legales en todas partes del mundo).
Los sistemas concurrentes en realidad solucionan parte del inconveniente creando un estado intermedio de la compra, en una tabla transaccional que luego relacionan con la de facturación, pero sólo a los efectos de la consistencia de datos.
Esta tabla transaccional solo debe ser consistente consigo misma, por lo que el orden numérico de su identificador es irrelevante.
¿Qué quiero decir con todo esto?
Bueno, simplemente creas una tabla de, digamos, "ordenDePedido", donde vas a cumulando todos los detalles necesarios para la emisión de la factura, y sólo al confirmar toda la operación tomas esos mismos datos y los vuelcas en la factura, en un sólo ciclo de proceso, recuperando en el acto el numero de factura que se genera .
¿Se entiende?
NUNCA usas una tabla de facturas como tabla de proceso previo. JAMÁS.
Usas siempre tablas intermedias y la ejecución de facturación es un proceso atómico de cierre final.

Una factura nunca debe tener procesos posteriores que modifiquen datos una vez emitido su identificador. Toda modificación de la operación asentada en una factura, siempre generará nuevos documentos a registrar en otras tablas, pero la factura en si se cierra junto con la generación de su identificador, y no se modifica.
Respecto a la consistencia tiempo-numero de factura, me refiero a que si si tienes dos facturas con números consecutivos, en todas las legislaciones que yo conozco, la factura de numero mayor siempre debe tener una fecha y hora posteriores, y eso puede no cumplirse en tu sistema (dependería de cuanto tarde la segunda transacción), con lo que existe margen para que la facturación sea legalmente considerada fraudulenta, si las horas de registración son inversas a la numeración. ¿Queda claro?

¿Se entiende la idea?

[gnzsoloyo]

con lo de los codigos a ver si entendi, es que no debo de tomar el numero incremental, si no que debo de dejar que se autoincremente al momento que se ingrese la factura, es asi? y si es asi comprendi que puede haber un error con la fecha y la hora de la creacion del documento, ya que si llamo primero el form, y otro en red llama el mismo form con el valor incremental siguiente, y hace el proceso primero que mi, y yo un par de horas despues quedaria con una fecha menor adelante de una mayor.

Exactamente ese tipo de inconsitencias es lo que legalmente se considera fraudulento,. Por eso se debe evitar lo que estás haciendo.
La factura se emite en el acto y se recupera el numero en el acto de cierre.

Si fuera asi,como harian los otros grandes sistemas de facturacion para obtener elcodigo primero alabrir el formulario de facturacion.

En los grandes sistemas de facturación las facturas se emiten en automático, de acuerdo a la hora de generación del cargo y su origen, como te menciono. Son procesos que realizan un sinnúmero de validaciones en un ciclo que suele durar varios días en el caso de clientes abonados a determinados servicios, o tal vez horas, cuando se trata de cargos puntuales de ventas. Las emisiones de las facturas, siempre están controladas por procesos que corren en background (demonios), que resuelven la consistencia de las facturas con sus emisiones. No son sencillos de describir.

En cualquier a de estos encontrarás que las operaciones iniciales se realizan por medio de tablas transaccionales intermedias que son las que recopilan los cargos.
Trabajo para una empresa de esas características, y lo que te describí en el posts anterior es, en forma muy simplificada, el modo en que opera la parte del sistema ocupada de las ventas a individuos.

[dimas18]

Comprendo tu respuesta y pues bien voy a remover lo de colocar los codigos en las facturas y voy a recuperar el codigo qal momento de insertar el registro.

Agradezco tu respuesta y bien,voy a aplicar tu consejo.
Muchas gracias.

ps: creo que este tipo de validacion no aplicaria al crear articulos, usuarios o empleados?

Iniciado por gnzsoloyo

Exactamente ese tipo de inconsitencias es lo que legalmente se considera fraudulento,. Por eso se debe evitar lo que estás haciendo.
La factura se emite en el acto y se recupera el numero en el acto de cierre.

En los grandes sistemas de facturación las facturas se emiten en automático, de acuerdo a la hora de generación del cargo y su origen, como te menciono. Son procesos que realizan un sinnúmero de validaciones en un ciclo que suele durar varios días en el caso de clientes abonados a determinados servicios, o tal vez horas, cuando se trata de cargos puntuales de ventas. Las emisiones de las facturas, siempre están controladas por procesos que corren en background (demonios), que resuelven la consistencia de las facturas con sus emisiones. No son sencillos de describir.

En cualquier a de estos encontrarás que las operaciones iniciales se realizan por medio de tablas transaccionales intermedias que son las que recopilan los cargos.
Trabajo para una empresa de esas características, y lo que te describí en el posts anterior es, en forma muy simplificada, el modo en que opera la parte del sistema ocupada de las ventas a individuos.

[gnzsoloyo]

ps: creo que este tipo de validacion no aplicaria al crear articulos, usuarios o empleados?

No. El ingreso de empleados, usuarios, artículos y otras cosas de ese tipo son el tipo de altas que se hacen de forma esporádica, y donde no es relevante la secuencialidad de lo identificadores autoincrementales. En realidad el análisis de las altas para antigüedad o precedencia se hace en base a la fecha de alta, que siempre se guarda como DATETIME o TIMESTAMP para eso. Por otro lado recuerda que ese tipo de datos son de uso administrativo interno a la emrpesa, en cambio la facturación no.
Además, las interfases desde donde se hacen esas altas son de uso muy restringido, es decir, no todos los usuarios deben poder dar de alta un artículo, ni a otro usuario. Por eso esas funcionalidades solo se usan de forma puntual, e incluso de se pueden hacer de modo diferido.
En cambio los proceso de facturación siempre tienen impacto inmediato, por lo que su secuencialidad es fundamental.

Ahora bien, una nota. En los casos donde el sistema no tenga concurrencia, o bien donde haya un manejo de transacciones muy bueno, de todos modos es posible usar métodos que te permitan administra los autoincrementales, si usas tablas InnoDB.
Requiere leer el manual de referencia, que está en inglés:
http://dev.mysql.com/doc/refman/5.7/...vel-locks.html
http://dev.mysql.com/doc/refman/5.7/...y-locking.html

Lo que sí NUNCA debes hacer es usar sentencias DDL como ALTER TABLE para realizar modificaciones como las que hacías. Son riesgosas, innecesarias, y además cualquier sentencia DDL que se ejecute generará un COMMIT implícito para todas las transacciones en curso, lo que podría dejar asentadas operaciones que no deben confirmarse, y hacer caer en error todas las transacciones que se estén ejecutando, si la llamada a su inicio y finalziación la manejas en la aplicación.

[dimas18]

Muyt claro todo lo comentado, y si me sirven los documentos que me colocaste acerca del bloqueo, actualizacion y demas, lo voy a leer detenidamente para aplicarlo,
gracias por tu asistencia.

Iniciado por gnzsoloyo

No. El ingreso de empleados, usuarios, artículos y otras cosas de ese tipo son el tipo de altas que se hacen de forma esporádica, y donde no es relevante la secuencialidad de lo identificadores autoincrementales. En realidad el análisis de las altas para antigüedad o precedencia se hace en base a la fecha de alta, que siempre se guarda como DATETIME o TIMESTAMP para eso. Por otro lado recuerda que ese tipo de datos son de uso administrativo interno a la emrpesa, en cambio la facturación no.
Además, las interfases desde donde se hacen esas altas son de uso muy restringido, es decir, no todos los usuarios deben poder dar de alta un artículo, ni a otro usuario. Por eso esas funcionalidades solo se usan de forma puntual, e incluso de se pueden hacer de modo diferido.
En cambio los proceso de facturación siempre tienen impacto inmediato, por lo que su secuencialidad es fundamental.

Ahora bien, una nota. En los casos donde el sistema no tenga concurrencia, o bien donde haya un manejo de transacciones muy bueno, de todos modos es posible usar métodos que te permitan administra los autoincrementales, si usas tablas InnoDB.
Requiere leer el manual de referencia, que está en inglés:
[url]http://dev.mysql.com/doc/refman/5.7/en/innodb-record-level-locks.html[/url]
[url]http://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html[/url]

Lo que sí NUNCA debes hacer es usar sentencias DDL como ALTER TABLE para realizar modificaciones como las que hacías. Son riesgosas, innecesarias, y además cualquier sentencia DDL que se ejecute generará un COMMIT implícito para todas las transacciones en curso, lo que podría dejar asentadas operaciones que no deben confirmarse, y hacer caer en error todas las transacciones que se estén ejecutando, si la llamada a su inicio y finalziación la manejas en la aplicación.