Bonjour,
j'avais posé ma question dans une autre rubrique, mais celle-ci est peut-être plus adaptée.
 
j'ai un petit service basé une table mySQL. Malheureusement lors dela conception de la table, j'ai oublié de rajouter l'attribut auto-increment sur la clef primaire 'id'.
Du coup, lorsque je veux rajouter des champs depuis une interface web, cela plante systématiquement.
 
J'ai essayé  

 
 
mais ca me renvoit toujours  
 

 
 
car j'ai déjà provisionné (à la main) des enregistrements dans la table.
 
Merci de votre aide.

t'es sûr que t'as pas de doublons dans ta table ?

hello,
ben a priori oui.
J'avais renseigner les champs avec mon interface web, avant d'essayer de rajouter la clef primaire.
Donc tous les champs 'id' étaient à 0 et je les ai manuellement modifié (c'était faisable, une quinzaine).
 
mais bon g pourtant bien vérifié et revérifié, il n'y a pas deux fois le même 'id'

Bon en fait, g trouvé:
g renommé mon champ d'id 11 en 14, puis à ce moment là il a bien voulu me passer la clef primaire en auto-increment.
 
Du coup après, j'ai essayé de modifier les ID pour les mettre dans l'ordre que je voulais, mais là il a bloqué, avec à nouveau une histoire de duplicate....
 
J'en déduis qu'en fait, il doit avoir son propre critère de classement des enregistrements et que derrière, qd tu définis un champ en clef primaire auto, il assigne lui-même la valeur de l'id; pas moeyn de changer.
 
De toute façon, pour ma table, je peux faire un classement sur la date, dc c pas trop important, mais je savais pas que mySQl utilisait d'autres critères que ceux intervenant dans la définition de la table.
 
Bon bref pb résolu.
 
Merci

=> l'id ne doit jamais être utilisé pour faire un tri. c'est une donnée purement interne. par contre, indexe bien ta date si tu t'en sert comme critère de tri

 
Oui, c'est bien quand on le sait... je suis pas super balèze en bdd.    
 
par contre, qu'entends-tu par indexer le champ date?
 
PS: comment on change le titre pr mette résolu devant?

1/ C'est pas une règle absolue non plus hein L'ID peut tout à fait être utilisé comme champ de tri, mais il ne faut entre autres, pas du tout lui faire confiance pour avoir la moindre valeur chronologique ou d'importance, ce serait une erreur.
2/ Créer un index, c'est à dire euh... Ben comme l'index d'un livre quoi : du coup le SGBD sait retrouver les données en fonction des champs indexés sans avoir besoin de lire la ligne dans la table. C'est très important en termes d'optimisation, surtout lorsque la volumétrie commence à grossir. Regarde la doc de ton SGBD à propos des INDEX pour avoir plus d'infos. Tu peux aussi jeter un oeil au lien "SGBD" dans ma signature, à un moment je parle un peu des index.
3/ Il suffit d'éditer ton premier post, et changer le titre

Merci de ta réponse,
je suis content, ça doit être à peu près le 1er pb que je pose qui a non seulement des réponses, mais aussi une solution !!!  
 
Effectivement, je crois que l'id peut être fiable à partir du moment où les choses sont automatisées dès le début. Ce qui devrait être le cas à partir de maintenant. Mais bon, de tte façon, je continue de travailler sur la date...
Quant à l'optimisation, cette base sert seulement à la diffusion de news sur mon site, donc le volume devrait rester très faible.
 
Encore merci
@++

je viens de jeter un oeil sur ton cours, c bien écrit et une très bonne initiative, bravo !
 
 
edit: je garde en bookmark pr la suite