Forum Clubic

[MYSQL] champ DATETIME - problème de mise à jour

Bonjour

J’utilise un champ dans mes tables au format DATETIME pour y stocker la date de la mise à jour de la table en question pour chaque enregistrement.

Je stock la date en même temps que mon enregistrement et tout semble bien marcher.

Mais quand je consulte mes enregistrement via phpmyadmin lors de controle ou de débuggage, je m’apperçois que dans une même table, tous mes enregistrement DATETIME prenent la valeur du dernier enregistrement…

Est-ce normal ? une chose m’échappe-t’elle dans la manipulation du format DATETIME ?

Si ça continue je vais devoir enregistrer la date en varchar ou autre format texte, de toute façon le php la récupère comme un string en résultat de requète, mais au moins vos réponses m’instruiront.

Tu fais quoi comme requête? Vérifie si tu ne mets pas par hasard des requêtes d’update qui touche toute la table. Sinon, montre voir le CREATE TABLE (exporter dans phpmyadmin, sans les données, sans les `).

Me semble (je dis bien “me semble”) qu’avec les DATETIME y a une petite magouille au niveau des dates, mais vu que je n’utilise pas souvent les DATETIME je ne peux pas te dire mieux.

En te répondant et en copiant/collant la requète UPDATE je viens de me rendre compte que j’oubliais, au moins pour la table que j’ai regarder, la partie “WHERE …” de ma requète, du coup effectivement je mets à jour toutes les dates de la table…

:whistle:

Je vérifit pour les autres…

Bizarement, en transformant mon champ datetime en varchar, ça marche bien, je comprend pas à la vue de ma requète la différence de comportement…

CREATE TABLE `uni9_systèmes` (
  `id` tinyint(4) NOT NULL auto_increment,
  `galaxie` tinyint(4) NOT NULL default '0',
  `système` smallint(6) NOT NULL default '0',
  `maj` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`galaxie`,`système`),
  KEY `id` (`id`)
) TYPE=MyISAM AUTO_INCREMENT=127;
UPDATE systèmes SET maj = '$date';

Au passage vaut il mieux le format DATETIME ou bine varchar est il tout aussi bien sachant que MYSQL n’aura jamais à travailler sur les dates, seul le php le fait

et $date contient quoi comme chaine ? dans le bon format ?

ta table me semble pas tres joli niveau clés : je la verrais plus comme ca :

CREATE TABLE uni9_systèmes (
id tinyint(4) NOT NULL auto_increment,
galaxie tinyint(4) NOT NULL default ‘0’,
système smallint(6) NOT NULL default ‘0’,
maj datetime NOT NULL default ‘0000-00-00 00:00:00’,
PRIMARY KEY (id),
UNIQUE KEY galaxie (galaxie,système)
) TYPE=MyISAM

ps : tu nous fournis la table uni9_systèmes et ta requete se base sur une table systèmes…erreur de ta part ?
ps2 : les accents c’est mal dans les nom de champ :slight_smile:

“uni9_” est un préfixe me permettant d’avoir plusieurs systèmes dans la même base, j’ai enlevé le préfixe dans la requète (car c’est une variable php) mais j’ai oublié de l’enlever dans la table aussi, mais sinon y a pas de problème e ce coté…

Ensuite la variable $date viens de la fonction date() de php avec le bon formatage (identique à celui de MYSQL par défaut) et aucun problème non plus de ce coté.

Pour les clefs et index de la table, à force de bidouiller la base de donnée j’ai fais des erreurs et en effet le résultat que j’ai collé est bizarre, entre autre chose l’id ne devrai pas etre un tinyint (je m’en suis apperçu quand l’id a bloqué à 127 :whistle: )

l’id est un index et les 2 autres sont bien “UNIQUE” et non “PRIMARY”

Pour les accents, ben 'en ai mis un peu partout, et pire ca me permet de différencier certains résultats :paf: entre différente table avec même champs plutot que de mettre des “as” dans mes SELECT… On peut pas plus crade, mais bon
1°) je suis pas un pro,
2°) ça marche bien
3°) je prendrai les bonnes habitudes quand je m’arracherai les cheveux pour faire marcher mes script pleins de bug :stuck_out_tongue:

La prochaine fois je ferai gaffe, mais c’est ce qui arrive quand on programe “à la volée” sans avoir iren prévu sur papier avant :pt1cable:

Hum… si tu veux pas utiliser les fonctions de date de mySQL, alors un CHAR est mieux peut être. Maintenant, je te conseillerai quand même le DATETIME car au besoin tu peux faire des tris dessus, et des formattages de data (voir fonction DATE dans la doc de mySQL)

Je garde le DATETIME, on ne sait jamais desfois que je veuille classer les résultats d’une requete d’apres la date…

Yep. Et n’oublie pas : http://dev.mysql.com/doc/mysql/en/date-and…-functions.html