Modifier le compteur de la clé primaire d'une table

**Feliperennes** · 13/12/2021, 21h40

Bonjour,
Pour une raison que j'ignore la clé primaire des enregistrements d'une table est passée d'un coup de 14 à 22, seul aléa que j'ai pu identifier c'est une coupure d'Internet au moment où j'enregistrais une ligne à distance, à la limite je comprendrais qu'on saute de 14 à 16 mais de là à arriver à 22 ...
Bref, je souhaiterais pouvoir modifier la clé primaire 22 pour la ramener à 15 et faire redémarrer le compteur pour que le prochain enregistrement soit 16. Quelqu'un pourrait-il m'aider ?
Pour votre info, je suis assez profane en matière de SQL

Merci

**AaâÂäÄàAaâÂäÄàAaâÂäÄ** · 13/12/2021, 22h31

S'il y a eu réservation de valeurs sans que la transaction se conclue, c'est sûr que le compteur peut sauter des valeurs.
La question fondamentale est, est-ce que c'est un RÉEL problème d'avoir des trous dans la PK ?
Si non, on passe à un autre appel

Si la réponse est oui alors il faut changer de stratégie.

**Feliperennes** · 13/12/2021, 23h22

Non ce n'est pas un réel problème, c'est juste cosmétique mais j'aime les choses propres

**escartefigue** · 14/12/2021, 14h24

Ce genre de cosmétique qu'il ne faut pas faire, c'est du travail inutile et récurrent, le phénomène pouvant se reproduire à tout moment.
Les "trous" de numérotation peuvent être liés a des lignes non commitées (rollback explicite ou pas) ou des lignes supprimées, voire, c'est plus rare, à un forçage volontaire d'une "plage de trous" ayant pour vocation d'accueillir des lignes issues d'un système externe dont on connait le nombre.

Par ailleurs, il faut également savoir que les valeurs de ces types d'identifiants ne sont pas toujours chronologiques, dans un environnement multithread il arrive que le chrono 100 soit inséré avant le chrono 99.

À partir de là, la cosmétique il faut oublier, ce n'est absolument pas la vocation de ce type d'attributs.

Pire encore, les "identity" étant le plus souvent des clefs primaires, les renuméroter dans la table dont ils sont issus aurait par effet cascade un impact sur toutes les tables où cette même colonne est clef étrangère. On tire donc sur une toute petite ficelle mais on peut ramener toute la pelote et renuméroter des millions ou des milliards de lignes.

Bref une très, mais alors très très mauvaise idée.

**Feliperennes** · 15/12/2021, 10h48

Tout ça je le sais bien, notamment la clé primaire d'une table servant de lien avec un enregistrement d'une autre table.
Dans le cas présent, il s'agit d'un nouveau projet avec des essais donc les conséquences sont limitées. Il serait plus facile de suivre la chronologie des choses si la numérotation était respectée. Dans un projet abouti avec des millions de lignes évidemment que les sauts passeraient inaperçus.

**SQLpro** · 15/12/2021, 11h55

1) TRUNCATE TABLE réinitialise à l'origine la graine de l'IDENTITY
2) DBCC CHECKIDENT permet de redéfinir la graine à une valeur quelconque.

A me lire : https://blog.developpez.com/sqlpro/p...vec_sql_server

A +