Discussion :

[yannick34]

Bonjour,

je débute dans l'utilisation de SQLserver et je dois,dans le cadre d'un projet de formation, développer une base de données.
Mon problème est le suivant:
j'ai crée plusieurs tables avec un auto-incrément sur la clés primaires,mais sur certaines ce dernier ne fonctionne pas correctement, c'est à dire qu'il "oublie" des valeurs,ça me donne des suites du genre 1,2,3,4,7,8,9 dans la colonne auto-incrémentée.
Si quelqu'un a une solution ça serait vraiment sympa!!!!
merci!!

[elsuket]

Bonjour,

SQL Server "n'oublie" pas des valeurs : lorsque vous supprimez une ligne ou que la transaction d'insertion échoue, la valeur de compteur de la colonne est supprimée, mais la valeur du compteur pour la colonne est incrémentée.

Je n'ai jamais compris le problème que cela pose, car la plupart du temps il s'agit d'une clé purement logique, et on se moque de l'ordre dans lequel les tuples que stocke la table apparaissent.
Rappelons qu'en SQL, il n'y a pas d'ordre : les colonnes comme les lignes peuvent apparaître dans n'importe quel "ordre", le tuple conserve la même valeur ({1,2,3} équivaut à {2,1,3} par exemple).

@++

[Népomucène]

Si c'est la première fois que vous utilisez des auto-incréments,
c'est vrai que c'est déroutant : on a l'impression d'un "gâchis" de numéros

En fait, comme l'a dit elsuket, ces numéros n'ont pas de signification pour l'utilisateur.
On ne doit s'en servir que pour des usages techniques comme la mise en relation de tables entre elles
(on pourrait, comme Access en offre la possibilité, prendre des nombres au hasard).

L'auto-incrément est ce qu'il y a de plus robuste pour identifier un enregistrement.
Comme le numéro est à usage unique, on est sûr, techniquement, d'identifier chaque enregistrement. C'est une clé primaire idéale.
La contrepartie est que dès qu'un utilisateur commence à faire une saisie, un numéro est retenu.
Si l'utilisateur annule finalement sa saisie, le numéro est "perdu".

C'est pourquoi on ne doit pas utiliser l'auto-incrément pour numéroter des factures par exemple
(la suite des numéros de facture ne doit pas comporter de trous).
On doit alors recourir à une numérotation dans un champ séparé.

La seule signification (pour le développeur) que peut avoir un auto-incrément
est d'indiquer l'ordre dans lequel les enregistrements ont été créés.
C'est parfois utile pour savoir ce que les utilisateurs ont fabriqué

[Sergejack]

Suite à ce que disait Elsuket, pour avoir une solution, il faut d'abord un problème.

Si problème il y a (quand même), quel est-il ?

[SQLpro]

Si l'utilisateur annule finalement sa saisie, le numéro est "perdu".

C'est pourquoi on ne doit pas utiliser l'auto-incrément pour numéroter des factures par exemple
(la suite des numéros de facture ne doit pas comporter de trous).
On doit alors recourir à une numérotation dans un champ séparé.

FAUX : le seul cas ou le n° est perdu est le cas de la suppression, pas de l'annulation d'une saisie en cours !

A +

[Népomucène]

FAUX : le seul cas ou le n° est perdu est le cas de la suppression, pas de l'annulation d'une saisie en cours !

J'ai mal rédigé, SQL n'a, en effet, pas ce comportement en cas d'annulation de saise.
J'étais resté sur le comportement d'Access 2000 qui lui,
"brûle" un numéro en cas d'annulation de saisie dans une table Access.
Mes excuses les plus plates pour cette confusion ...

[Sergejack]

Mes excuses les plus plates pour cette confusion ...

Il reste une confusion sur ta formule de politesse
"les plus plates", c'est ironique.

[Népomucène]

Ah bon, mes excuses les plus montagneuses alors ...

[SQLpro]

Un jour Frédéric Lemaître hué par des spectateurs qui n'avait rien compris à la pièce qu'il jouait, a eu cette admirable phrase pleine de contresens :
"Je vous ais traité d'imbécile, c'est vrai !
Je m'en excuse... j'ai tort !"

A +