pb de valeur decimale

par **Sékiltoyai** » 02 nov. 2007, 10:40

Ouais mais la recherche sur le site de MySQL n'est pas terrible, par rapport à la recherche sur le site de PHP. Ils auraient gagné à faire un moteur de recherche dédié.

par **Hubert Roksor** » 02 nov. 2007, 10:10

Oui, tout à fait. Le manuel anglais est mis à jour plus souvent et contient parfois des paragraphes importants qui n'ont pas encore été traduits en français. D'ailleurs, il faudrait que je me renseigne sur leur équipe de traduction pour potentiellement donner un coup de main, si quelqu'un a une info/URL à ce sujet faites passer merci

Pour info, quand je dois chercher quelque chose dans le manuel, c'est vers la version 5.1 que je me tourne et je le fais via une recherche personnalisée (grâce à Opera, mais Firefox possède la même fonction) via l'URL http://www.google.com/search?q=%s+site: ... man/5.1/en (où %s représente les termes de la recherche)

par **Sékiltoyai** » 02 nov. 2007, 09:49

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 ?

Non, la citation de Hubert, elle signifie que selon le mode du serveur, lorsqu'on entre une valeur trop grande (resp. trop petite), soit la valeur est ramenée à la valeur maximale (resp. minimale), soit le serveur déclenche une erreur.

Hubert, le manuel est plus complet en anglais du coup ? (si c'est le cas, j'abandonne le manuel français… )

par **Hubert Roksor** » 02 nov. 2007, 06:09

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é.

par AB » 02 nov. 2007, 03:23

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 ?

par **Sékiltoyai** » 02 nov. 2007, 02:52

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…

par **Hubert Roksor** » 02 nov. 2007, 02:38

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.

par **h0_noMan** » 02 nov. 2007, 02:11

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.

par **Invité** » 02 nov. 2007, 01:56

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

par **Invité** » 02 nov. 2007, 01:55

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?

par **Invité** » 02 nov. 2007, 01:51

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.

par AB » 01 nov. 2007, 22:03

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

par **Sékiltoyai** » 01 nov. 2007, 20:54

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…

par **Invité** » 01 nov. 2007, 20:30

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

par **Sékiltoyai** » 01 nov. 2007, 19:43

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

pb de valeur decimale

Répondre

Étendre la vue Revue du sujet : pb de valeur decimale