Forum d'entraide PHPFrance

Bonjour à tous,
j'ai un site ecommerce qui tourne actuellement en ligne sur MySQL: 5.0.21.
En local, j'ai le même site sous MySQL 4.1.9-max.

Dans ma table produits, j'ai un champ prix en decimal(5,2).

Quand je fais une importation de produits sur la version en ligne (mysql 5.0.21), tous les prix au dessus de 999.99 sont remplacés par 999.99.
Par exemple, un produit à 1800.00€ devient un produit à 999.99€ après importation.

Quand je fais la même opération en local (MySQL 4.1.9), pas de pb, mes prix sont intacts.
Voyez vous d'où ça peut venir?

Merci pour vos réponses.

Quelles est la structure de ta table Produits ?

Sous forme de CREATE TABLE.

CREATE TABLE `produits` (
  `idLivre` varchar(10) NOT NULL default '0',
  `chapeau` varchar(255) NOT NULL default '',
  `auteur` varchar(255) NOT NULL default '',
  `titreSousTitre` varchar(255) NOT NULL default '',
  `editeurLieuAnnee` varchar(255) NOT NULL default '',
  `debutEdition` varchar(4) NOT NULL default '0000',
  `finEdition` varchar(4) NOT NULL default '0000',
  `formatCollation` text NOT NULL,
  `description` text NOT NULL,
  `prix` decimal(5,2) NOT NULL default '0.00',
  `noticeBib` text NOT NULL,
  `themes` varchar(255) NOT NULL default '',
  `motsClef` varchar(255) NOT NULL default '',
  `nomCat` varchar(255) NOT NULL default '',
  `dateAjout` date NOT NULL default '0000-00-00',
  `modeAjout` varchar(10) NOT NULL default '',
  `imageUrl` varchar(100) NOT NULL default '0',
  `setImage` tinyint(1) NOT NULL default '0',
  `trash` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`idLivre`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

C'est tout à fait normal. decimal(5,2) signifie un affichage de 5 chiffres, dont 2 chiffres pour la partie fractionnaire, d'où une valeur maximale de 999,99
Doc mysql sur les types numériques : http://dev.mysql.com/doc/refman/5.0/fr/ ... types.html

Mon champ prix est en decimal (5,2) en ligne comme en local.
Comment expliquer que le pb ne se pose qu'en ligne?

Aucune idée, mais en tous cas il est logique que cela se passe sur le serveur de production.
A la limite poste ton shéma de table de ta base locale pour voir si le type de donnée est correct…

A la place de decimal tu peux aussi mettre float pour tester.

Aucune idée, mais en tous cas il est logique que cela se passe sur le serveur de production.
A la limite poste ton shéma de table de ta base locale pour voir si le type de donnée est correct…

Je comprends pas ce que tu veux dire...le type de données c'est bien decimal (5,2) pour le prix? je peut garantir que tout est identique en ligne et en local, car ma version locale est un dump de la base qui était en ligne...c'est à en devenir fou, c'est la première fois que je vois ça!

Je vais changer mon decimal (5,2) en autre chause car ce que vous avez dit à ce sujet a du sens, mais c'est frustrant de ne pas comprendre cette différence de comportement.
Si qqn a des suggestions, elles sont les bien venues.

voici ce que j'ai dans le schéma de table en local, et c'est pareil en ligne.

prix   decimal(5,2)  Non  0.00

Y aurait pas un truc avec le champ decimal qui se comporte de manière différente selon les versions?

...je parle des versions de mysql...

De toute façon, si tu as des chiffre important à mettre dedans, il te faut changer par une valeur qui conviendras mieux.

Essayes un prix de 1000,01€ sur ta base en local.

Je ne vois pas où est le problème, tu déclares une colonne numérique contenant des valeurs de 5 chiffres dont 2 après la virgule, quand tu rentres des valeurs plus grandes elles se retrouvent tronquées, conformément à ton souhait.

Si tu veux stocker des valeurs plus grandes, utilise le type de données adapté, point.

When asked to store a value in a numeric column that is outside the data type's allowable range, MySQL's behavior depends on the SQL mode in effect at the time. For example, if no restrictive modes are enabled, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead. However, if the mode is set to TRADITIONAL, MySQL rejects a value that is out of range with an error, and the insert fails, in accordance with the SQL standard.

Hubert, le problème c'est aussi qu'il est bizarre que cela se comporte très bien en local, car si, je suis d'accord avec toi, le comportement en production est totalement logique, le comportement en local est lui, plutôt bizarre, surtout que dans la doc, ils ne parlent à aucun moment de différences entre des versions 4 et des versions 5.

La seule différence se trouve entre avant et après la 3.23, et encore, dans l'autre sens, à savoir qu'avant la 3.23, la taille prenait en compte la totalité des caractères stockés (moins, chiffres, et point), et après la 3.23, elle ne prenait en compte que les chiffres significatifs, donc on pouvait stocker moins de chiffres avant qu'après… Alors que dans notre cas, il peut stocker beaucoup plus en local sur sa version 4 que sur le serveur, ce qui est illogique au regard de la doc…

Hubert, le problème c'est aussi qu'il est bizarre que cela se comporte très bien en local, car si, je suis d'accord avec toi, le comportement en production est totalement logique, le comportement en local est lui, plutôt bizarre, surtout que dans la doc, ils ne parlent à aucun moment de différences entre des versions 4 et des versions 5.

Heu, j'suis pas un as en anglais loin s'en faut, mais l'explication ne se trouverait-elle pas dans la citation du manuel php faite par Hubert ?

Pas vraiment, le changement lui-même est décrit dans le chapitre 23.2. Changements de type de données avec DECIMAL (au passage, je note que les numéros de chapitres sont systématiquement différents entre la VO et la VF, dans le genre pratique on fait difficilement mieux)

L'extension non standard MySQL de la limite supérieur de stockage des colonnes DECIMAL n'est plus supportée.

Considérez le comportement de l'ancienne version de MySQL comme un bug qui a été corrigé.

Forum d'entraide PHPFrance

pb de valeur decimale

pb de valeur decimale