![]() |
Error de Primary Key
Hola como estan todos, espero que bien.
Nesecito ayuda urgente con este error, miren la imagen: https://mail.google.com/mail/?ui=2&i...f_gtrbw26v0&zw |
alguien puede ver la imagen?
|
Perdon si no se puede ver la imagen esto es lo que dice el error:
General SQL Error. lock conflict on no way transaction violation of PRIMARY or UNIQUE KEY contraint 'CITAS_PK' on table CITAS. Disculpen por la imagen. |
Lo normal es que estés dando de alta un registro con la misma primary key que otro.
|
Pero como puedo resolver, ya que al momento de grabar un registro en la esta tabla me da ese error.
|
Pues poniéndole otro código, lo normal 1, 2, 3, 4, 5, etc...
|
verifica que el codigo que estas grabando no se esté repitiendo
|
Sino puedes generar automáticamente el código con un generador, puedes lanzar un SQL que verifique si ese registro ya existe, todo esto antes de intentar grabarlo.
Un Saludo. |
Cita:
INSERT INTO TABLA (Campo1,ID) VALUES (@Valor,@ID) ELSE UPDATE TABLA SET Campo1 = @Valor WHERE ID = @ID HAY ESTA CAVAL MODIFICA ESTE QUERY PODRAS MODIFICAR EL CAMPO DUPLICADO |
Bienvenido a clubdelphi, por favor, lee nuestra guía de estilo, gracias.
|
Cita:
En firebird también exista una sentencia "update or insert", pero en este caso no valdría porque si el código es creado por otro usuario entonces estaríamos actualizando el mismo en lugar de crear uno nuevo nosotros. Del blog de jhonny: http://jhonny.clubdelphi.com/2010/08...-1-recuperado/ |
Yo en estos casos tengo una tabla que almacena un contador, primero lo incremento en 1 y luego ese número se lo doy al documento/factura.
Me gustaría ver que otras opciones utilizais, para generar una numeración consecutiva sin saltos. Me funciona pero quisiera ver otras opciones. Un Saludo. |
Si quieres números consecuentivos entonces descartamos un generador.
No mantengo contadores porque me parecen innecesarios y una fuente potencial de problemas. Para esos casos yo compruebo el ultimo número dado de alta y le sumo uno. Si alguien ha dado de alta ese número mientras tanto, pues vuelvo a pedir de nuevo el último y le sumo 1, y así varias veces. Si transcurridos varios intentos están siempre ocupados los números que voy pidiendo es que algo anormal ha ocurrido y ya saco el mensaje de error. He modificado un trozo de código, simplificándolo, a ver si no me he equivocado, pero al menos sirve para que se entienda lo que hago. Uutiles.pas (datos de configuración del programa)
Cualquier otra Unit.pas -------------------------------------------------
|
También he utilizado algo similar, pero tengo un problema.
Año:2011 --->Factura=11+0000 110001 110002 115200 El 11 lo extraigo de un Campo que llamo ejercicio, no lo cojo directamente de la fecha, porque puede que el cliente quiera hacer todavía a principios de Enero algunas facturas con fecha del año anterior que tiene pendientes. Año:2012--->Factura=125201 Yo quiero que al cambiar el año, esto lo hago con la tabla contadores. 1.-Llegado el momento, cambio el ejercicio. 2.-Cambio los contadores de Facturas - Albaranes - Pedidos etc. Año:2012--->Factura=120001 Un Saludo. |
Hola.
Esto quiero recordar que lo hemos comentado alguna vez. Yo particularmente creo que lo más sano es mantener una tabla de contadores con el número completo porque, aunque no es frecuente, es posible que el cliente quiera dejar un rango de facturas vacias para hacerlas posteriormente. El único problema es que si anulas la última factura y quieres reutilizar ese número tienes que retroceder el contador manualmente. En mi aplicación en particular a cada factura se le asigna una serie 'A-' 'B-', etc... y cada serie tiene sus contadores de albaranes, facturas, tickets, etc. y documentos de impresión independientes. De esta manera dependiendo de la serie de factura saldrá con un formato u otro y tendrá una numeración u otra. El número de factura se compone de la serie+el número que corresponda según el contador, p.e.: A-110001,B-110032, etc. Saludos |
La franja horaria es GMT +2. Ahora son las 23:01:13. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi