Discussion :

[Monkey_D.Luffy]

Bonjour,

J'ai une table Client, dont le champ Id_client s'incrémente au fur et à mesure des insertions.

Code SQL :

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

Create Table Client    (Id_client int not NULL IDENTITY PRIMARY KEY);

Comment savoir quel Id_client aura la prochaine insertion ?
Car actuellement, je remplis par exemple la table avec 35 clients. Je vide ensuite la table, puis j'insère un client. Celui-ci aura un Id_client = à 36. Mais comment le savoir, avant de l'insérer ?

Merci.

[ylarvor]

c'est quoi l'interet de le savoir avant, juste aprés, dans la procedure d'insertion, tu peux faire avec @@identity...

reference : http://msdn.microsoft.com/fr-fr/library/ms187342.aspx

[Monkey_D.Luffy]

Merci.

En fait c'est pas indispensable que je sache avant l'insertion, mais comme je fais un formulaire d'insertion (Java/JDBC), je voulais afficher dans le formulaire l'Id_client qu'aura la prochaine insertion.

Sinon, ton lien m'a été doublement utile : j'avais un autre soucis, c'était que les attributs Id_clients ne se suivaient pas toujours, dans ma table. J'avais parfois des "trous", comme décrit dans l'article.

"La variable @@IDENTITY ne revient pas à une valeur précédente en cas d'échec de l'instruction INSERT ou SELECT INTO, d'échec d'une copie par bloc ou d'une restauration de la transaction.

Les instructions et les transactions qui ont échoué peuvent modifier l'identité actuelle pour une table et créer des écarts dans les valeurs de colonne d'identité. La valeur d'identité n'est jamais restaurée même si la transaction qui a essayé d'insérer la valeur dans la table n'est pas validée. Par exemple, même si une instruction INSERT échoue en raison d'une violation IGNORE_DUP_KEY, la valeur d'identité actuelle pour la table est incrémentée. "

Donc ça me rassure que ça soit normal, mais comment éviter ce genre de désagrément ? Par un trigger, c'est possible ? Y a-t-il + pratique ?
Merci.

[ylarvor]

Donc ça me rassure que ça soit normal, mais comment éviter ce genre de désagrément ? Par un trigger, c'est possible ? Y a-t-il + pratique ?

Il est vivement recommandé d'utiliser un IDENTITY pour référencer les enregistrements! C'est une technologie fiable. Si tu développes toi même une identity, tu vas au devant de problème...

[SQLpro]

comment éviter ce genre de désagrément ? Par un trigger, c'est possible ? Y a-t-il + pratique ?

effectivement si vous voulez pourrir les performances de votre base, le meilleur moyen est de tenter cela. En effet le seul moyen d'obtenir cet effet est de vérouilleer la totalité de la table en mode exclusif pendant toute la durée de la saisie. Ainsi si l'utilisateur met 3 minutes à saisir, personne ne pourra ni lire, ni encore moins écrire dans la table...

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/clefs/

A +

[Monkey_D.Luffy]

Merci pour l'article. La solution de la table des clés a l'air efficace (bien que compliquée pour un débutant comme moi), mais je pense que je vais garder la fonction IDENTITY comme vous me l'avez suggéré.

Merci et bonne journée.