Bonjour
Je travail sur MySQL, et je veux recuperer le numero de id qui sera du next enregistrement à inserer.
Par exemple , j ai les numeros   1,2,3,4,5,6,7
j ai supprimé 6,7
il reste 1,2,3,4,5
mnt moi je veux avoir une fct Mysql qui me donne 8.
Merci

Bonjour,
LAST_INSERT_ID()  
 
???
pas certain (2 jours de mysql)
Cordialement

c'est la bonne réponse, sauf que ça ne répond pas à la question.
 
en fait, le procédé est mauvais : mise à part avec l'utilisation de séquences (Oracle par exemple) il est impossible de connaître à l'avance le numéro d'ID qui sera généré, simplement parcequ'on ne peut garantir qu'entre le moment où on récupère ce numéro et le moment où on écrit effectivement dans la base, personne n'a déjà pris ce numéro.
 
ainsi, on doit toujours créer la ligne, et récupérer immédiatement après le numéro en question. jamais l'inverse.
 
ceci est faux avec Oracle, puisqu'Oracle utilise des séquences, qui permettent de "réserver" l'ID généré : deux appels successifs à NextVal() donnent deux résultats différents, permettant ainsi de s'assurer que personne ne prendra le numéro réservé.
c'est totalement spécifique au fonctionnement d'Oracle (on le retrouve sur PostGre aussi) qui ne supporte pas les champs "numeroauto".

Bonjour,
Un grand merci pour les précisions. Il est vrai que, dans mon petit coin, j'ai toujours tendance à ne plus raisonner multiposte.
Cordialement

c'est vrai aussi sur DB2  

En fait, à la base, ça devrait être identique pour tous le monde : les séquences font partie de la norme SQL92, et tous les SGBD devraient les supporter.
 
Mais Microsoft à choisi le type "numeroauto", qui est bien plus simple à utiliser, car ne nécessite pas de faire de trigger ou une insertion en deux étapes.
On retrouve donc ce type dans mal pasl d'autres SGBD, dont MySQL (qui en plus, bouche les trous, ce que ne prévoit pas le numéroauto tel que prévu par Microsoft).
 
A la demande de Microsoft, ce nouveau type a été ajouté à la norme SQL avec la norme SQL99 ou autre.
 
Mais SQL92 restant la norme de référence, force est de constater que nombre de SGBD ne supportent toujours pas correctement cette norme.