C'est toujours un problème très courant chez de nombreux développeurs et applications, quelle que soit leur taille.
Malheureusement, les suggestions ci-dessus ne résolvent pas tous les scénarios, c'est-à-dire l'hébergement partagé, vous ne pouvez pas compter sur votre hôte pour définir le paramètre de démarrage -t272.
En outre, si vous avez des tables existantes qui utilisent ces colonnes d'identité pour les clés primaires, supprimer ces colonnes et en recréer de nouvelles pour utiliser la solution de contournement de séquence BS est un effort ÉNORME. La solution de contournement de séquence n'est bonne que si vous concevez les tables à partir de zéro dans SQL 2012+
En bout de ligne, si vous êtes sur Sql Server 2008R2, restez sur lui. Sérieusement, restez dessus. Jusqu'à ce que Microsoft admette qu'il a introduit un bogue ÉNORME, qui est toujours là même dans Sql Server 2016, nous ne devrions pas mettre à niveau jusqu'à ce qu'ils le possèdent et FIX IT.
Microsoft a tout de suite introduit un changement radical, c'est-à-dire qu'ils ont cassé une API fonctionnelle qui ne fonctionne plus comme prévu, du fait que leur système oublie leur identité actuelle lors d'un redémarrage. Cache ou pas de cache, c'est inacceptable, et le développeur Microsoft du nom de Bryan doit le posséder, au lieu de dire au monde qu'il est "par conception" et "fonctionnalité". Bien sûr, la mise en cache est une fonctionnalité, mais perdre la trace de ce que devrait être la prochaine identité, N'EST PAS UNE FONCTION. C'est un BUG fricken !!!
Je vais partager la solution de contournement que j'ai utilisée, car mes bases de données sont sur des serveurs d'hébergement partagé, et je ne supprime pas et ne recrée pas mes colonnes de clé primaire, ce serait un énorme PITA.
Au lieu de cela, c'est mon hack honteux (mais pas aussi honteux que ce bogue de point de vente que Microsoft a introduit).
Hack / Fix:
Avant vos commandes d'insertion, réalisez simplement votre identité avant chaque insertion. Ce correctif n'est recommandé que si vous n'avez pas de contrôle administrateur sur votre instance Sql Server, sinon je suggère de réensemencer au redémarrage du serveur.
declare @newId int -- where int is the datatype of your PKey or Id column
select @newId = max(YourBuggedIdColumn) from YOUR_TABLE_NAME
DBCC CheckIdent('YOUR_TABLE_NAME', RESEED, @newId)
Juste ces 3 lignes juste avant votre insertion, et vous devriez être prêt à partir. Cela n'affectera pas vraiment les performances, c'est-à-dire qu'il sera imperceptible.
Bonne chance.
order by ReceiptNo
à votre requête, ces enregistrements ne sont-ils vraiment pas là? Êtes-vous sûr qu'il n'y a pas d'erreur lors de l'insertion d'enregistrements? Si un enregistrement tente d'être inséré et échoue, l'identité s'incrémentera, même chose si les enregistrements sont supprimés. Si des enregistrements sont supprimés, le fichierReceiptNo
n'est pas réinitialisé. Pouvez-vous publier la table de création pour laFee
table?