El problema es que esta mal modelado desde el principio y creo que no tuviste en cuenta la concurrencia que pudiera darse. A veces efectivamente es por milesimas de segundo pero sucede. Supongamos que un puesto esta dando de alta un cliente (A) y al mismo tiempo otro puesto hace lo mismo(B). Digamos que tienes el ultimo numero en 100. Entonces A checa y calcula el proximo en 101, al mismo tiempo B hace exactamente lo mismo y obtiene obviamente el mismo valor (suponemos que como A no ha guardado aun su informacion el valor 100 no se ha movido). Entonces A finalmente guarda sus datos sin problemas e inmediatamente despues de eso B intenta guardar. Como esta usando la misma clave, y suponemos que esta correctamente definida la clave principal para evitar duplicados, el manejador de BD no permite guardar (duplicate Key error) y el registro que se intentaba guardar se pierde (el de B). Obviamente todo esto paso en fracciones de segundo.
Por que es un mal modelo? Porque aun suponiendo la situacion anterior, el sistema deberia poder recuperarse del error en la clave y ya sea mandarle el mensaje al usuario sin perder el registro o bien incrementar la clave una vez mas hasta conseguir poder guardarlo. En "La cara oculta" de Marteens trae un capítulo que habla de este problema y el manejo de transacciones, seguro te servirá.
Una solucion mucho mas sencilla, es usar en tu table de clientes un campo autoincrementado (Paradox lo soporta) y asi te olvidas ya que es Paradox quien se encarga de asignar las claves y obviamente nunca se presenta el problema que vimos ya que la clave sea asigna justo al momento de guardar el registro por lo que es imposible que se pierda.
Por último:
Cita:
|
La verdad es que me da mucha perza remodelar todo por eso solo.
|
Recuerda el conocido refrán: "El flojo y el mezquino andan dos veces el camino"..
27-11-2006
Temas Similares
Modo Hilado