Autoincrement con identity
Me da mucho gusto poder contar contigo.
Mi pregunta es la siguiente: como puedo restablecer el valor de un campo identity a 0. Trabajo con sybase 12.5
Mi pregunta es la siguiente: como puedo restablecer el valor de un campo identity a 0. Trabajo con sybase 12.5
1 respuesta
Respuesta de Antonio Garcia
1
Un campo identity es una variable que se autoincrementa basado en un algoritmo que permite contener un valor único.
Su valor inicial depende del algoritmo el cual puede estar relacionado, combinando la hora, fecha, registro, etc.
Este valor inicial es dado cuando la tabla es creada, y será incrementado conforme el algoritmo antes mencionado.
La manera más practica de inicializar el contador, es creando de nuevo la tabla.
Sin embargo cada vez que la tabla graba una nueva tupla, este es incrementado en uno, teniendo en cuenta que nunca deberá repetirse.
Lo más acertado en este caso es crear un campo el cual puedas controlar programaticamente, sin embargo esto es inventar el agua con azúcar, pues al final te encontrarías validando que el numero que generes, no puede existir dentro de tu tabla, y deberá incrementarse cada vez que se graba una tupla.
Puede que se te ocurra particionar la data, por ejemplo, renombrando la tabla que contiene tu data actual, y creando una nueva, por supuesto esta inicializa su contador, sin embargo si quisieras unir o unificar la data en una única tabla (posteriormente), tendrás que tener en cuenta que entre tabla y tabla puede repetirse el valor del campo IDENTITY, y esto te llevaría a crear uno nuevo esto en caso que tu deseo es mantenerlo, por lo contrario, el traslado de la data a una única tabla, no integraría el campo identity, aunque la nueva si lo tenga, pero al final, te encuentras con un circulo vicioso.
Personalmente pienso que el utilizar un campo identity puede ser una solución extrema, teniendo en cuenta que antes de utilizar este recurso, puedes diseñar una forma de identificar una tupla y evitar que aunque la combinación de los campos en la llave primaria provoquen una repetición.
Por ejemplo
En una cabecera de una factura puedes tener como llave primaria
la serie + el numero
y en el detalle
la serie + el numero + un numero de linea
En este caso el detalle es reconocido individualmente por el numero de linea que ocupa en la factura.
Su valor inicial depende del algoritmo el cual puede estar relacionado, combinando la hora, fecha, registro, etc.
Este valor inicial es dado cuando la tabla es creada, y será incrementado conforme el algoritmo antes mencionado.
La manera más practica de inicializar el contador, es creando de nuevo la tabla.
Sin embargo cada vez que la tabla graba una nueva tupla, este es incrementado en uno, teniendo en cuenta que nunca deberá repetirse.
Lo más acertado en este caso es crear un campo el cual puedas controlar programaticamente, sin embargo esto es inventar el agua con azúcar, pues al final te encontrarías validando que el numero que generes, no puede existir dentro de tu tabla, y deberá incrementarse cada vez que se graba una tupla.
Puede que se te ocurra particionar la data, por ejemplo, renombrando la tabla que contiene tu data actual, y creando una nueva, por supuesto esta inicializa su contador, sin embargo si quisieras unir o unificar la data en una única tabla (posteriormente), tendrás que tener en cuenta que entre tabla y tabla puede repetirse el valor del campo IDENTITY, y esto te llevaría a crear uno nuevo esto en caso que tu deseo es mantenerlo, por lo contrario, el traslado de la data a una única tabla, no integraría el campo identity, aunque la nueva si lo tenga, pero al final, te encuentras con un circulo vicioso.
Personalmente pienso que el utilizar un campo identity puede ser una solución extrema, teniendo en cuenta que antes de utilizar este recurso, puedes diseñar una forma de identificar una tupla y evitar que aunque la combinación de los campos en la llave primaria provoquen una repetición.
Por ejemplo
En una cabecera de una factura puedes tener como llave primaria
la serie + el numero
y en el detalle
la serie + el numero + un numero de linea
En este caso el detalle es reconocido individualmente por el numero de linea que ocupa en la factura.
Muchas gracias, me parece muy noble que alguien ocupe parte de su tiempo ayudando a otros.
Bueno yo podría volver a crear la tabla, pues estuve haciendo pruebas en ella y quería blanquearla para que el usuario pudiera capturar. Pero investigando dicen que hay una sentencia que resetea el valor a 0, sin borrar la estructura de la tabla, decía que un procedimiento, trate de ejecutarlo pero no me funciono, algo así como sa_resetidentity[basedatos, nombre de la tabla, 0].
Si no puedes informarme al respecto, un millón de gracias por tu información al respecto
Bueno yo podría volver a crear la tabla, pues estuve haciendo pruebas en ella y quería blanquearla para que el usuario pudiera capturar. Pero investigando dicen que hay una sentencia que resetea el valor a 0, sin borrar la estructura de la tabla, decía que un procedimiento, trate de ejecutarlo pero no me funciono, algo así como sa_resetidentity[basedatos, nombre de la tabla, 0].
Si no puedes informarme al respecto, un millón de gracias por tu información al respecto
No estoy muy familiarizado con los procedimientos de la version 12.1 de sybase,
sin embargo te comento que hasta donde yo tengo conocimiento los procedimientos que están disponibles en las versionas antiores o por lo menos hasta la version 10 sybase inician con sp_
Así pues podrías probar con sp_resetidentity[basedatos, nombre de la tabla, 0]
Sin embargo como te comentaba en la respuesta anterior
tienes que tener mucho cuidado al hacer un reset al campo identity, pues este verifica que la cantidad nueva a asignar, no exista en la tabla como tal, puede que en lugar de 1 (asumiendo que incias en 0) te coloque una cantidad inesperada, teniendo en cuenta que el numero 1 ya esta registrado en dicho campo y termines encontrándote que el reset de del campo identity si funcionó, pero cuando este tuvo que incrementar dicho numero colocó el siguiente inmediato según la ultima tupla grabada.
Permíteme insistir un poco con respecto a invitarte a tomar una salida alterna a el reset del campo identity, pues es posible que en el futuro esto pueda convertirse en un problema mayor.
sin embargo te comento que hasta donde yo tengo conocimiento los procedimientos que están disponibles en las versionas antiores o por lo menos hasta la version 10 sybase inician con sp_
Así pues podrías probar con sp_resetidentity[basedatos, nombre de la tabla, 0]
Sin embargo como te comentaba en la respuesta anterior
tienes que tener mucho cuidado al hacer un reset al campo identity, pues este verifica que la cantidad nueva a asignar, no exista en la tabla como tal, puede que en lugar de 1 (asumiendo que incias en 0) te coloque una cantidad inesperada, teniendo en cuenta que el numero 1 ya esta registrado en dicho campo y termines encontrándote que el reset de del campo identity si funcionó, pero cuando este tuvo que incrementar dicho numero colocó el siguiente inmediato según la ultima tupla grabada.
Permíteme insistir un poco con respecto a invitarte a tomar una salida alterna a el reset del campo identity, pues es posible que en el futuro esto pueda convertirse en un problema mayor.
