Discussion :

[Soticca]

Bonjour à tous,

Nous avons récupéré une application en Access dont les tables proviennent d'une base MS SQL Server ayant au moins 10 ans d'existence.

Il y a une table dont la colonne servant de clé primaire est définie en tant que : int (4) avec une "identity (1,1).

Étonnamment, arrivé à 12528, l'auto incrément est passée à 13528, puis ensuite à 14528 etc... alors qu'on a toujours (1,1) en définition d'identity.

Ne connaissant pas trop MS SQL Server, j'avoue que je patauge un peu sur ce problème. Auriez vous déjà vu ce genre de phénomène ? Avez-vous une piste pour remettre d'aplomb l'auto incrément ?

Merci d'avance.

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

int (4)

Tiens, un nouveau type de données SQL Server que je ne connaissais pas

Étonnamment, arrivé à 12528, l'auto incrément est passée à 13528, puis ensuite à 14528 etc... alors qu'on a toujours (1,1) en définition d'identity.

Si votre application a «réserver» 10000 id qui n'ont pas été validé, c'est normale que l'on fasse un saut de 10000 dans la colonne ensuite.
Cela dit ça ressemble également très fort au comportement d'une colonne définie avec un identity(1, 10000).

Auriez vous déjà vu ce genre de phénomène ? Avez-vous une piste pour remettre d'aplomb l'auto incrément ?

Vérifier comment votre applicatif insère les données dans la bd.
Vérifier aussi la définition de votre colonne.
Et il ne faut pas oublier qu'au final une pk n'a pas de sens fonctionnel, donc ça ne devrait même pas être un problème d'avoir une suite non continue.

[Soticca]

Bonjour,

Je sais bien qu'une PK ne devrait pas avoir de signification fonctionnelle malheureusement, quand on reprend une application on "subit" les structures qui ont été mise en place et je confirme que l'identity est bien définie en (1,1).

C'est Access qui insère la nouvelle ligne via du code standard sans aucun recalcul ou quoi que ce soit d'autre.

D'ailleurs, depuis que j'ai posté ce message on est repassé en pas de 1 Donc maintenant on a 12358, 13358, 14358 puis 14359, 14360, 14361 etc...

Cette application n'ayant pas pour vocation à survivre à l'année 2024, on va continuer à surveiller sans plus.

Merci pour la réponse.

[escartefigue]

Possiblement, un traitement qui commit ses insertions par paquets de 1 000 a fait des rollback, auquel cas, les identifiants non commités sont perdus, ça expliquerait les trous de 1 000 successifs.
Un redémarrage de serveur peut également vider le cache et faire perdre des valeurs, mais en ce cas, on n'aurait pas des "trous" de même taille.

Une remarque : la notion d'auto_increment est un terme spécifique à MySQL / MariaDB. SQL server utilise des IDENTITY

[SQLpro]

Ce saut est généré par la mise en cache de l'auto-incrémentation par IDENTITY... qui travaille de 10 000 en 10 000 pour des rasions de performances.

Vous pouvez le désactiver avec la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF;

Néanmoins, je ne le ferais personnellement jamais....
Mais si vous voulez vous assoir sur les performances.....

A +

[Soticca]

Merci pour les réponses.

Petite question sur la mise en cache pour ma gouverne personnelle. Quelle est la raison de son exécution sachant que ce n'est pas une table contenant beaucoup de ligne ? (aucune envie de désactiver cette fonctionnalité)

[escartefigue]

La mise en cache a pour but d'éviter de solliciter le moteur à chaque insertion, les performances en sont augmentées, mais, en contrepartie, il peut y avoir des pertes en cas de redémarrage du serveur.