Ver Mensaje Individual
  #2  
Antiguo 16-07-2003
andres1569 andres1569 is offline
Miembro
 
Registrado: may 2003
Posts: 908
Reputación: 22
andres1569 Va por buen camino
Hola:

La solución que planteas me parece acertada, a la hora de grabar miras el último NTICKET asignado y grabas ese número + 1, así tienes números correlativos, sin huecos, y la clave primaria COD va por su cuenta, que es donde ligas los detalles de tickets. Pero de todas formas no te evitas el tener un mecanismo que grabe el NTICKET correspondiente, es decir el último y correlativo. Por esto, tanto si usas la misma clave primaria como número de ticket como si usas un campo auxiliar, éste deberá estar indexado como UNIQUE, para que el motor proteste en caso de duplicidades (es la mejor manera de asegurarnos). Y el valor que tome ese NTICKET se va a decidir en la grabación, claro está, no antes.

Puede ser interesante tener una tabla auxiliar donde almacenas el último número de ticket grabado, y de ahí tomas la información, de manera que cuando te dispones a grabar un ticket tomas ese valor de esa tabla y lo incrementas. Ten en cuenta que deberás idear algún mecanismo, ya sea por bloqueos o manualmente, mediante algún semáforo, para evitar que nadie acceda a ese registro antes de que lo incrementes, para que no tome un valor equivocado.

La verdad es que yo suelo usar un SELECT MAX() y ninguna tabla auxiliar. De esta forma, cuando insertas un nuevo registro (en OnNewRecord), asignas en NTICKET el número que le corresponde del SELECT MAX, (si se conectan diez terminales o si abres diez nuevos tickets desde la misma terminal, todas tomarán el mismo número). Hay que tener en cuenta que ese número es testimonial y en muchos casos no será el que se grabará. A la hora de grabar, me quedo esperando el error de índice duplicado; si ese NTICKET ya existe porque alguien se adelantó, intercepto el error (lo hago usando ApplyUpdates e intercepto el evento OnUpdateError), si falla es porque alguien ha grabado antes y vuelvo a lanzar el SELECT MAX() y vuelvo a grabar. Así hasta que el ticket es aceptado (te hablo de cómo lo tengo en mis programas, no te hablo de TPVs ni de tickets, pero puede servir). Quizás, dependiendo de tu aplicación y de tu motor de BD, sea una solución lenta, pero creo que es efectiva.

Sobre el tema de lectores de códigos de barras, se ha tocado varias veces en estos foros y en los antiguos. Tengo una rutina que discrimina el código recibido de un lector del recibido del teclado, pues ambos generan el mismo evento. Lo tengo implementado mediante el evento OnMessage de TApplication, aunque quizás lo ideal sea hacerlo mediante Hooks de teclado, ahora que se han puesto de moda en los foros.
__________________
Guía de Estilo
Responder Con Cita