Discussion :

[renaud26]

Bonjour à tous,

Je viens de réaliser un export de mon serveur distant, en gzip, pour import sur mon local via PhpMyAdmin.
Mais problème : les champs datetime se corrompent au passage. Une suite de 0 s'ajoutent.

Sur le distant : 2013-09-20 09:44:23
En local après import : 2013-09-20 09:44:23.000000

Distant :
Version du serveur : 5.1.73-1+deb6u1 - (Debian)
phpmyadmin : Version : 4.1.14.8

Local :
Version du serveur : 5.6.15-log - MySQL Community Server (GPL)
phpmyadmin : Version : 4.1.4, dernière version stable : 4.3.7

D'où cela peut-il venir ?
Merci de vos conseils.

[tatayo]

Bonjour,
Je ne vois aucune corruption de donnée, mais juste des "pouillèmes" de secondes ajoutés à tes données.
Je suppose donc que le format du timestamp n'est pas le même entre les deux bases de données.

Tatayo.

[renaud26]

Bonjour,

Oui ce sont sans doute des pouillèmes de secondes
Mais ces pouillèmes font échouer ma requête WEEK(champ_datetime).
Ennuyeux. Et je ne vois aucune différence de structure entre les champs.

[escartefigue]

il ne s'agit pas de dégradation mais de formats différents
le site distant est en datetime
le site local en timestamp (précision = nanoseconde)
Il y a donc eu conversion de forma, et les nanosecondes manquantes ne peuvent évidemment pas être calculées par le loader

J'en profite pour rappeler que le timestamp n'est pas une clef unique, contrairement à ce que j'ai souvent lu ou entendu

[renaud26]

Bonjour,

Tu dis que mon champ local est en timestamp. Quand je regarde la structure de la table dans MyAdmin, je ne vois que "datetime", exactement comme sur le distant.
Et je ne vois pas de possibilité d'affiner cela en terme de précision. Peux-tu m'en dire plus ?

[escartefigue]

Bonjour,

Tu dis que mon champ local est en timestamp. Quand je regarde la structure de la table dans MyAdmin, je ne vois que "datetime", exactement comme sur le distant.
Et je ne vois pas de possibilité d'affiner cela en terme de précision. Peux-tu m'en dire plus ?

Et bien si MySQL confond les format DATETIME et TIMESTAMP c'est vraiment dommage car la précision à la nanoseconde, dans une base de donnée digne de ce nom, est un format timestamp et non datetime
Attention toutefois de bien vérifier le format des colonnes dans le script de création (DDL) et non via certains outils d'affichage qui dégradent les attributs véritables de la base de données

[renaud26]

Attention toutefois de bien vérifier le format des colonnes dans le script de création (DDL) et non via certains outils d'affichage qui dégradent les attributs véritables de la base de données

Cela dépasse mes compétences. Quand j'ai fait mon export depuis le distant, j'ai inclus un drop table. Donc structure et données ont été importés en local.
Ensuite à l'affichage, je vois la différence de date. Je suppose que c'est en local que je dois modifier ma structure...mais comment ? Où?