|
|
05/06/2007, 08h22
|
#1 |
|
Junior Member
Date d'inscription: April 2007
Messages: 29
|
Erreur 1062 sur un champ auto incrémenté
Bonjour,
je rencontre ce problème suite à une coupure d'électricité ... J'exécute une requête : "INSERT INTO `ma_table` SET `mon_champ`='ma_valeur';" MySQL me répond : [MySQL][ODBC 3.51 Driver][mysqld-5.0.37-community-nt]Duplicate entry '27305' for key 1 La table `ma_table` ne comporte que 2 champs Le champ `mon_champ` est de type varchar et n'est pas unique ni indexé ... etc. Par contre l'autre champ est ma clé primaire et est auto-incrémenté. Je suppose que le calcul de l'auto-incrémentation s'est désynchronisé par rapport à ce champ indexé ... Que puis-je faire pour réparer cela ? Merci bien d'avance !!! |
|
|
|
05/06/2007, 09h20
|
#2 |
|
Junior Member
Date d'inscription: April 2007
Messages: 29
|
Bon; j'essaye quelque-chose :
je fais une boucle de last_insert_id() jusqu'à MAX() et je fais la requete : "REPLACE INTO `ma_table` SET `champ_id`=valeur_de_boucle AND `mon_champ`='la_même_valeur_qu_avant';" Ma question : est-ce qu'à chaque appel mysql incrémente-t'il l'auto-incrément malgré que je fournisse la valeur de l'ID (un ID qui existe déjà) et que j'appelle REPLACE et pas INSERT ? Merci |
|
|
|
|
05/06/2007, 12h45
|
#3 |
|
ancien admin
Date d'inscription: September 2005
Localisation: Paris
Messages: 1 214
|
Ta syntaxe d'insertion n'est pas conventionnelle. Lorsqu'on fait un INSERT, la bonne syntaxe est :
Code:
Utiliser SET se fait dans une requête UPDATE et doit en principe comporter une clause restrictive WHERE sur un identifiant afin de ne pas mettre à jour toute la table avec la même valeur. |
|
|
|
|
05/06/2007, 16h28
|
#4 |
|
Junior Member
Date d'inscription: April 2007
Messages: 29
|
OK merci beaucoup !!!
 |
|
|
|
|
05/06/2007, 16h32
|
#5 |
|
Junior Member
Date d'inscription: April 2007
Messages: 29
|
Est-ce à cause de cette syntaxe que j'ai rencontré mon problème d'erreur 1062, ou même avec la conventionnelle (la tienne) je risque de rencontrer le même problème ?
|
|
|
|
|
05/06/2007, 21h15
|
#6 |
|
ancien admin
Date d'inscription: September 2005
Localisation: Paris
Messages: 1 214
|
Avec ma méthode, si la colonne est bien en AUTO_INCREMENT, tu n'auras aucun problème. Quant à l'autre méthode, j'avoue que je ne sais pas trop mais il est probable qu'elle est la cause de l'erreur, ce n'est pas vraiment du SQL standard.
|
|
|
|
|
03/07/2009, 15h41
|
#7 |
|
Junior Member
Date d'inscription: April 2007
Messages: 29
|
Bonjour bonjour,
2 ans sont passés, et me revoilà ...  Depuis quelques temps, et malgré une utilisation conventionnelle de l'insertion (que je n'ai pas changé depuis 2007), je rencontre souvent dans mes différentes installations le même problème récurrent, avec cette erreur 1062 (toutes les 2 semaines à 1 mois). Je corrige le problème en appelant la fonction REPAIR sur la table : la valeur de l'auto-incrément est réévaluée à sa juste valeur. La table qui rencontre ce problème supporte des requêtes de sélections sur les derniers enregistrements tout les 1/30e de secondes par 2 à 10 postes en intranet. Aucune requête de suppression n'est effectuée sur cette table. Les requêtes d'insertions s'étalent dans la journée (il peut y en avoir plusieurs centaines dans une journée et jusqu'à quelques milliers plus rarement). D'où peut venir ce problème de décallage ? Surtout que, quand le mal est fait et que je regarde, l'auto-incrémentation est en retard de plusieurs enregistrements (ex : auto-incrément à 505253 alors que max(id) = 505267). Voici la structure de la table pour tout cas ... : Code:
Merci beaucoup par avance pour toute l'aide et toutes les suggestions que l'on pourrait me faire. |
|
|
|
 |
| Outils de la discussion | Rechercher |
| Modes d'affichage | |
|
|
Mode linéaire
