.net - existing - La identidad SQL(autonumber) se incrementa incluso con una reversión de transacción

sql server add identity column to existing table (8)

Tengo una transacción .net con una inserción de SQL en una base de datos de SQL Server 2005. La tabla tiene una clave primaria de identidad.

Cuando se produce un error dentro de la transacción, se Rollback() . Las inserciones de fila se retrotraen correctamente, sin embargo, la próxima vez que inserte datos en la tabla, la identidad se incrementa como si nunca se hubiera producido la retrotracción. Entonces, esencialmente, hay lagunas en la secuencia de identidad. ¿Hay alguna forma de que el método Rollback() recupere la identidad que falta?

¿No me estoy acercando a esto de la manera correcta?

Hasta donde yo sé, las filas para inserción reclaman el autonumero y al deshacer ese número se pierde para siempre. Si depende de que ese autonumber esté en secuencia, es posible que desee considerar el enfoque que está utilizando.

Muhan intenta pensar en ello en el contexto de muchas conexiones simultáneas que ejecutan esta transacción y no una a la vez. Algunos fallarán y otros tendrán éxito. Desea que SQL Server se concentre en ejecutar las nuevas solicitudes a medida que entran y no en mantener una columna de identidad sin espacio. OMI (vacíos en los valores) es definitivamente algo en lo que no vale la pena dedicar tiempo.

No creo que haya ningún requisito de que las claves autonumentadas sean secuenciales. De hecho, no creo que se les pueda exigir que sean:

la transacción a comienza y se inserta
la transacción b comienza y se inserta
transacción a aborta
obtienes un hoyo nada que hacer al respecto.

No. Las implementaciones de secuencia usan una transacción autónoma. En Oracle, la transacción autónoma fue una vez interna a los dbms, pero ahora está expuesta para su propio uso (y a menudo se usa de forma incorrecta)

PRAGMA AUTONOMOUS_TRANSACTION;''

Obtienes espacios en tu secuencia si DELETE una fila también.

Se requiere que las secuencias sean únicas, pero no se requiere que sean secuenciales. El hecho de que sean monótonamente crecientes es solo una casualidad de la implementación.

Si lo piensas, el número de incremento automático no debe ser transaccional. Si otras transacciones tuvieran que esperar para ver si el número automático se usaría o "revertiría", se bloquearían mediante la transacción existente utilizando el número automático. Por ejemplo, considere mi código de psuedo a continuación con la tabla A usando un campo de número automático para la columna de ID:

User 1 ------------ begin transaction insert into A ... insert into B ... update C ... insert into D ... commit User 2 ----------- begin transaction insert into A ... insert into B ... commit

Si la transacción del usuario 2 comienza un milisegundo después del usuario 1, entonces su inserción en la tabla A tendría que esperar a que se completara la transacción completa del usuario 1 para ver si se utilizó el número automático de la primera inserción en A.

Esto es una característica, no un error. Recomendaría utilizar otro esquema para generar números automáticos si los necesita para que sean estrechamente secuenciales.

Si usted depende de que sus valores de identidad no tengan espacios vacíos, entonces sí, lo está haciendo mal. El objetivo de una clave sustituta es no tener ningún significado comercial .

Y, no, no hay forma de cambiar este comportamiento (excepto rodar su autoincremento, y sufrir las consecuencias en el rendimiento de bloquear otras inserciones).

Todos los otros carteles que dicen que no deben preocuparse por eso, y que deben obtener lagunas, tienen razón. Si hay un significado comercial para el número, y ese significado no coincide con los vacíos, entonces no use una columna de identidad.

Para su información, si por alguna razón usted quiere eliminar las lagunas, la mayoría de las bases de datos tienen una forma de resevear la numeración automática al número que usted elija. Es un dolor en el culo, y si te encuentras que necesita hacerlo regularmente, definitivamente no deberías estar usando un campo de autonumeración / identidad, como se señaló anteriormente. Pero aquí está el código para hacerlo en el servidor SQL:

DBCC CHECKIDENT (''Producto'', RESEED, 0)

Eso establece que la tabla de productos vuelva a comenzar en 1 (aunque si tiene registros en la tabla, obviamente omitirá los valores de ID que ya se tomaron). Otros proveedores de RDBMS tienen su propia sintaxis, pero el efecto es más o menos el mismo, así que busque "restablecer identidad" o "reiniciar autonumber" en los archivos de ayuda del sistema o en los internets.

De nuevo: esto es para ocasiones especiales, no de uso regular. No lo pongas en un procedimiento almacenado y haz que todos vayamos allí.