Dans la famille "on en apprend tous les jours", aujourd'hui, l'utilisation des colonnes de type IDENTITY comme compteur dans une table.

Je ne le savais donc pas (la faute, je trouve, à la documentation totalement inexistante à ce propos), mais l'incrémentation des valeurs des colonnes IDENTITY sous Sql Server est totalement déconnectée de toute notion de transaction.

Conséquence directe : si vous effectuez un rollback après une insertion dans une table avec une colonne identité, la valeur du compteur sera consommée et perdue pour la ligne suivante (vous aurez donc un trou dans votre séquence).

Autant la documentation semble parler de trous pouvant survenir lorsque l'on efface des lignes (ce que je conçois tout à fait), autant il m'a fallu me retrouver devant le fait accompli pour constater cette limitation.

Conclusion (on avait déjà quelques tables se servant d'un compteur interne pour générer la séquence, donc on va juste accélérer la migration vers ce mécanisme), n'utilisez pas les colonnes IDENTITY si vous souhaitez avoir une vrai séquence sans trous (même si vous n'effacez pas vos lignes !).

Commentaires

  1. Vko
    10 nov. 2007 17:47

    MSDN Fr :

    "Les instructions et les transactions qui ont échoué peuvent modifier l'identité actuelle pour une table et créer des écarts dans les valeurs de colonne d'identité. La valeur d'identité n'est jamais restaurée même si la transaction qui a essayé d'insérer la valeur dans la table n'est pas validée. Par exemple, même si une instruction INSERT échoue en raison d'une violation IGNORE_DUP_KEY, la valeur d'identité actuelle pour la table est incrémentée. "

    Tu es pardonné jeune padawan (ok je savais pas non plus et je n'ai jamais eu cette contrainte :) )

  2. Styx31
    10 nov. 2007 18:38

    Ah oui, tiens, j'avais pas vu ça sur la doc de @@IDENTITY.

    Disons que ça pourrait apparaitre dans la doc sur le mot-clé IDENTITY plutôt.

  3. Mimetis
    12 nov. 2007 11:50

    Ah je savais pas non plus, merci Styx31

Laissez un commentaire