Bonjour,
 
Je suis rompu à l'utilisation de MYSQL et du langage SQL, après 10 ans de pratique voici que pour la première fois je me trouve totalement bloqué alors peut être parviendrez-vous à m'aider :
 
La manœuvre n'a rien de compliquée, j'update une table avec les valeurs contenues dans une autre, voici la requête :
UPDATE Calcul C, PreCalcul P SET C.Val=P.Val, P.Val=0 WHERE C.User=P.User AND C.User=\"".$User."\" AND P.Val > 0
 
Cette requête est appelée dans une boucle while, la valeur de $User change à chaque tour de boucle. L'utilisation d'une boucle plutôt que de faire un seul update pour tous les users découle d'une autre obligation non concernée par ce problème.
 
Mon problème c'est qu'il y-a, pour chaque User, une dizaine de données qui doivent être mises à jour, et que depuis peu (sans n'avoir modifié le code), certaines données pour certains users ne se mettent pas à jour. Les données oubliées sont toujours les mêmes.
 
Le plus étrange, c'est que l'Update oublie ces données quand il tourne en tache Cron et traite des milliers de Users, mais n'oublie aucune donnée quand je le relance la tache Cron à la main pour le User lésé !
 
Une idée ?
 
Merci d'avance.

Peut-être que P.val serait nul et que donc son contenu serait indéterminé.

Bien entendu j'ai vérifié que les données oubliées dans l'update sont censées être modifiées, ce qui est d'ailleurs fait quand je relance le script à la main !
 
Je pense qu'un des enregistrements est corrompu, mais des réparations de table n'y font rien. Pour le prochain lancement du script, j'ai isolé l'enregistrement que je pense être fautif, on verra bien si ça marche.
 
Quelqu'un sait s'il peut arriver qu'un doublon soit stocké dans la base malgrés la présence d'une clé primaire (et donc l'impossibilité de doublon) ? Des tests me font penser que j'ai un enregistrement en double qui ne serait pas visible car théoriquement impossible, et ferait planter l'Update !

Vive mySql. Faut passer à quelque chose de sérieux. Quand j'entend ça ça fais peur.

et tu as creusé du coté de la casse ou d'un espace qui traine a la fin?

ce sont des float (pour les Valeurs) et oui, pour le nom du User j'ai vérifié vu que ça marche quand je relance le même script moi même, ça ne peut donc pas venir du script lui-même !

Il ne faut pas être aussi affirmatif. L'environnement n'est pas le même. Les données non initialisées n'ont pas forcément la même valeur. L'un des piège est la gestion des données nulles. Par exemple P.Val peut être supérieur à zéro tout en étant nul, ou bien être égal à zéro en étant nul. Cette requête comporte un risque car elle ne teste pas si P.val est nul ou non avant de tester sa valeur. Mais peut-être que P.val est une donnée qui n'est jamais nulle. Si vous répondiez à la question, alors on pourrait éliminer cette première hypothèse et passer aux autres hypothèses.
 
Les clés primaires sont gérées dans les index. Si un index est corrompu, le plus simple serait de le récréer. Il ne s'agirait pas d'une réparation de table, mais d'une réparation d'index. Je ne sais pas très bien comment cela se fait avec MySQL, mais je suppose qu'il faudrait renommer la table, créer une table comme celle d'origine, et copier les données dans cette nouvelle table.

Je confirme, P.Val n'est jamais nul, en tout cas sur les lignes qui bloquent, il ne l'est pas.
 
Sinon merci pour l'idée des index etc, mais j'ai déjà tenté de recréer la table en la remplissant avec la première. Je l'ai fait via une requête (pas de changement), puis via une boucle php qui reremplissait la seconde base données après données, en ayant fait un select distinct sur la clé primaire pour être certain de ne pas avoir de doublons (pas de changement non plus).
 
Au final je suis certain qu'un enregistrement est corrompu, je l'ai viré et ça a réglé le pb, mais je pense qu'il y-en a d'autres que je n'ai pas repéré, donc ma question, existe t'il un moyen de vérifier qu'une table est corrompue et de la corriger (autre que le REPAIR qui ne marche pas dans ce cas) ?