hola amigos,

Tengo la siguiente situación:

un servidor de base de datos MYSQL Server 5.5 ubuntu 14.04 en RACKSPACE.
tengo una tabla llamada facturas con la siguiente estructura:

Tipo INNODB,
Id  int(10) autoincrement primari key
sec int(10) not null comment "secuencia de facturas"

el campo "sec" lo consulto para saber cual es el numero de factura siguiente
le aplico un UPDATE y sumo 1.

La idea es que hay varios terminales accediendo para validar facturas y en ocasiones
le asigna un numero de factura igual a dos facturas diferentes, "UN VERDADERO CAOS".

He utilizado este procedimiento  y no me funciona
"SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;"

contenido en el manual de MYSQL
Mysql

Nota: si uso un servidor local funciona muy bien,
el problema es cuan uso el de rackspace.

Gracias.

La solución que apuntas en el manual de Mysql no es aplicable al caso que presentas. Además, los bloqueos manejados manualmente son muy delicados... ¿Cuánto tiempo lo bloqueas? ¿Hasta que el usuario bloqueador pulse grabar? ¿y si se va a desayunar sin hacerlo?¿y si el servidor le corta la conexión por time-out o símplemente apaga el ordenador?

Creo que el problema se puede enfocar de una manera mucho más simple:
En la definición de la tabla el campo sec, te sobra. Utiliza el campo id es decir la clave primaria como número de factura pero primero quítale el atributo de autoincrement. Declaralo  como primary key simplemente y eso lo hace único y te deja a ti la tarea de controlar qué numero se graba. Averiguar el número que toca a la hora de crear un registro es muy simple, con un :

Tienes el número del último que se grabó, le sumas uno y ese es el que asignas al campo id del nuevo registro.

Si en el proceso de grabación, otro usuario intenta crear una factura y "te roba el número", no pasa nada, pues en el update se generará un error y tú lo puedes interceptar y solucionar o planterarselo al usuario y que lo solucione él.

Así el tema sería en pseudo código:

averiguas el número que toca y lo muestras en pantalla->
el usuario rellena la pantalla y pulsa "grabar"->
ejecutas un update. |- > El update es correcto -> fin o
                    |- >  El update fracasa (hay otro registro grabado en el mismo número)-> Averigua el nuevo número y
                                  |->graba (de manera que el usuario ni se entera) o
                                  |->avisa al usuario de lo que a ocurrido y Cambia el número en la pantalla para que sea él el que vuelva a pulsar "Grabar"


No crees el registro y luego le presentes el número a la pantalla para "tenerlo pillado" porque el usuario puede arrepentirse y no validar los datos con lo que tienes una factura vacía en la base de datos.

===================
No podemos regresar

La solución de shordi es interesante, pero hay que tocar la base de datos y quitar el autoincremento, si no tienes problemas con eso, adelante con esta solución.
Ahora si no puedes tocar la base de datos, lo que si puedes hacer es crear un "nombre" para la factura que pones en el campo de nombre, descripción o alguno similar, con un código random o "añomesdiahoraminutosegundomilisegundo"
insertar el registro y recuperar la clave primaria que te asigne el gestor de bases de datos, en este caso MySQL, con una consulta a la base de datos usando ese código.
Es bastante poco probable que dos o mas usuarios envíen una consulta SQL al mismo tiempo al nivel del mili segundo.

Saludos.

Hola,

muchas gracias por sus respuestas.

La solución de shordi estaría bien para una empresa que genera pocas facturas al día,
pero en este caso es una farmacia que tiene tres sucursales, cada una con mas de tres
ordenadores generando facturas (se generan mas de 1,000 facturas al día), así que no
fue factible aplicar dicha solución ya que el sistema se notaba muy lento.
Con respecto a la segunda solución que plantean es muy parecida a una que implemente,
es una super llave, compuesta por el codigo de usuario y el número de factura. pero no
me conforme hay. tambien utilice un servidor local en cada sucursal, de modo que la
secuencia de facturas se obtiene en la intranet y no se duplica ningun numero de factura,
y si ocurre, la super llave me evita miles de poblemas.

Gracias.

alessandri escribió: [Ver mensaje]

...Con respecto a la segunda solución que plantean es muy parecida a una que implemente,
es una super llave, compuesta por el codigo de usuario y el número de factura. pero no
me conforme hay. tambien utilice un servidor local en cada sucursal, de modo que la
secuencia de facturas se obtiene en la intranet y no se duplica ningun numero de factura,
y si ocurre, la super llave me evita miles de poblemas.

Podrías pasar un esquema del sistema, parece interesante, como genera cada usuario dichas facturas, con una aplicación de escritorio linux/gambas? o todo ocurre en un servidor y accedes via un navegador?

Saludos.

Hola amigos,

Tan pronto tenga un poco de tiempo publicare información
suficiente y relevante sobre como estoy tarjando actualmente
los sistemas remotos-local. (por poner un nombre).

Les adelanto que es una forma de hacer bases de datos distribuidas
con un sincronizador "muy rápido y confiable" que desarrolle.
(tuve muchos problemas con la replicación en mysql server 5.1
por esto me anime a desarrollar el sincronizador)

En pocos días estere publicando el proyecto.

alessandri escribió: [Ver mensaje]

...En pocos días estere publicando el proyecto.

Espectcular, estaremos a la espera.

Saludos.

Hola amigos,

adjunto el material que había prometido
sobre generación de secuencias, balanceo
de carga y sincronía de servidores.

Espero les sea de ayuda.

Hola amigos,

adjunto el material que había prometido
sobre generación de secuencias, balanceo
de carga y sincronía de servidores.

Espero les sea de ayuda.

(Adjunto parte 2)

A falta de poder ponerlo a funcionar, te envío mi agradecimiento por compartir algo tan interesante y útil que al fin y al cabo, es producto de tu trabajo y horas de dedicación.

Enhorabuena.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"