Discussion :

[DenisUrçay]

Bonjour et merci de me lire,

J'ai une table enregistrant des évènements ( fiches de vols d'avions ) numérotés, le numéro étant séquentiellement donné pas SQLSERVER ( Express ). La colonne "numero" est donc parfaitement incrémentée mais au bout que quelques centaines de numéros ( 300 en l’occurrence ) l'index passe d'un coup au lieu de 302 à 3202 ... et reprend son court normal puis re-saute encore ... je ne comprends pas pourquoi ... Une idée ? Merci par avance.

Denis

[vttman]

Bonjour
En passant ... (je ne suis pas spécialiste de SQL Server)
J'ai trouvé cette explication pour un gap de 1000 dans l'incrément
=>

The CACHE keyword (without an explicit cache size) uses the default server cache size - which is probably 1000 (just like for the IDENTITY columns). So SQL Server in the background caches the next 1000 sequence numbers. If your server crashes or unexpectedly restarts, those cached sequence numbers are "lost" (as in your case here, obviously).

Le CACHE mot-clé (sans taille de cache explicite) utilise la taille de cache du serveur par défaut - qui est probablement de 1000 (tout comme pour les IDENTITYcolonnes). Ainsi, SQL Server en arrière-plan met en cache les 1000 prochains numéros de séquence. Si votre serveur plante ou redémarre de manière inattendue, ces numéros de séquence mis en cache sont "perdus" (comme dans votre cas ici, évidemment).

[DenisUrçay]

Bonjour et merci ! Effectivement, c'est une piste, de plus piste probable dans le sens ou, l'application étant et cours de développement, il arrive assez souvent que des erreurs implique une sortie pas très propre ... je pioche encore ... autrement, j'ai commencé à bosser sur une séquence indépendante de la table ( CREATE SEQUENCE ) ... Le problème est que dans ce cas ça me donne pas mal de boulot pour corriger mon code en conséquence dans pas mal de classes .... mais comme disait ma grand-mère, faire et défaire c'est toujours travailler ...

[vttman]

.... mais comme disait ma grand-mère, faire et défaire c'est toujours travailler ...

On a eu la même grand-mère

[mikedavem]

Tu peux toujours utiliser NO CACHE pour minimiser l'impact mais ce n'est pas non plus garantie à 100%.
Je te conseille de mettre à jour pour qu'il ne soit pas sensible aux sauts dans la séquence. Si utilisé en tant que clé primaire, elle n'est pas d'autre but que d'identificateur unique de ligne.

++

[DenisUrçay]

Oui merci, je vais je pense utiliser une séquence par CREATE SEQUENCE puis recuperer mon numéro par NEXT VALUE FOR ... le numéro alimentera la colonne "numéro" de ma table, colonne qui sera clé primaire ... ainsi pas de doublon et une meilleure séquentialité ... non ?

[mikedavem]

En fait dans le contexte qui te concerne, je me serais posé la question d'utiliser une SEQUENCE vs IDENTITY.

Si tu n'as pas d'opérations extraordinaires sur la génération des numéros, que tu ne veux pas partager la séquence entre plusieurs tables, générer plusieurs numéros de séquence etc ... en gros un simple besoin d'incrémenter un numéro dans une table sur une clé primaire, IDENTITY t'offre ce que tu recherches => un moyen simple de générer des numéros incrémentaux, une bonne séquentialité même s'il ne te protège pas contre les gaps non plus.

++

[DenisUrçay]

Je vais utiliser les séquences si c'est important de ne pas avoir de " trous " ... et identity partout où l'on s'en fout ...
Merci a toutes et tous !

[tatayo]

Bonjour,
Même avec une séquence tu peux avoir des trous dans la numérotation, si par exemple l'application demande un numéro, et pour une raison ou une autre ne l'utilise pas.
La récupération d'un numéro ne tenant pas compte d'une éventuelle transaction en cours, même un ROLLBACK ne "libère" pas le numéro récupéré.

Tu as plus d'infos ici.

Tatayo.

[DenisUrçay]

Oui je comprends, c'est pour cela que dans l'appli c'est en dernier lieu que j'utilise le numéro ... avec NO cache ... pour plus de sureté ...

[SQLpro]

Je vais utiliser les séquences si c'est important de ne pas avoir de " trous " ... et identity partout où l'on s'en fout ...
Merci a toutes et tous !

JAMAIS aucune garantie qu'il n'y ai pas de trou. Par exemple en cas de ROLLBACK d'une transaction, qu'il soit explicite ou implicite (par exemple un verrou mortel) vous aurez systématiquement un trou...

Tant que vous penserez le contraire, vous ne serez pas à même de résoudre votre problème, qui d'ailleurs n'en est pas un !

A +

[DenisUrçay]

Bonjour et merci de votre réponse et de sa clarté ! J'ai bien compris et ne pense pas le contraire, simplement, il semblerait que les séquences en minimise ( il me semble ... ) la probabilité. D'autre part, cette application n'est susceptible de accueillir que deux postes et reste relativement simple. Pas d’accès direct à la base par les utilisateurs, s'il y a un trou de temps en temps c'est pas un drame. Ce que je ne désire pas, c'est des sauts de 100 ou 1000 ... d’où ma position. Si vraiment, sur le plan comptable, le responsable asso me dit qu'il ne veux plus de trous ... et bien je programmerai un compteur directement dans l'application ... En tous cas merci de votre intérêt qui me rend grand service et me permet de me coucher ( un peu ) moins tarte chaque soir !
Bien cordialement Denis

[Waldar]

Si vous ne voulez vraiment pas de trous, vous posez un verrou, faites un select max(Id) + 1 from LaTable et utilisez cet id jusqu'à ce que vous terminiez la transaction (commit ou rollback peu importe).

Par contre, votre code n'est plus appelable qu'en série. Si vous n'avez qu'un ou deux utilisateurs en parallèle ça peut être une option, mais gardez à l'esprit que la mise à l'échelle ne sera pas possible.

[SQLpro]

Bonjour et merci de votre réponse et de sa clarté ! J'ai bien compris et ne pense pas le contraire, simplement, il semblerait que les séquences en minimise ( il me semble ... ) la probabilité.

Absolument pas... Je dirais même que c'est pire, car IDENTITY est propre à une table tandis que la notion de séquence est un objet indépendant de la table, propre à la base !

D'autre part, cette application n'est susceptible de accueillir que deux postes et reste relativement simple. Pas d’accès direct à la base par les utilisateurs, s'il y a un trou de temps en temps c'est pas un drame. Ce que je ne désire pas, c'est des sauts de 100 ou 1000 ... d’où ma position. Si vraiment, sur le plan comptable, le responsable asso me dit qu'il ne veux plus de trous ... et bien je programmerai un compteur directement dans l'application ... En tous cas merci de votre intérêt qui me rend grand service et me permet de me coucher ( un peu ) moins tarte chaque soir !
Bien cordialement Denis

Une solution pour avoir une n° sans trou en sus de l'id auto incrémenté est d'utiliser une vue qui effectue un ROW_NUMBER() OVER(ORDER BY id).

A +