Bonjour à tous,

Dans quelques temps, je compte changer de serveur MySQL, et par la même occasion upgrader la base de données de 4.x vers 5.x. J'ai déjà entendu des echos comme quoi il n'y avait aucun problème de comptabilité entre les requêtes SQL, qui fonctionnent sur MySQL4 et ces mêmes requêtes sur MySQL5.

Toutefois, je ne compte pas faire ça à la légère, si je dois changer de version ça concernera les quelques dizaines de milliers de membres du site concerné. Bien sûr, je compte d'abord tester toutes les requêtes (tous les scripts) sur ce nouveau serveur, avec cette nouvelle version. Mais j'appréhende que quelque chose m'échappe.

En fait, y a t'il quelque chose qui fasse que, dans un certain cas, une requête qui fonctionnait sous MySQL 4 ait des réactions imprévisibles sur MySQL 5 ? Une infime modification qui fasse qu'une syntaxe soit interprétée differement, je sais pas... Toute info est bonne à prendre.

... et je vous serais reconnaissant des info que vous pourrez m'apporter

John

J'ai eu le cas sur un intranet, mais on était en 3.4x, et donc tout dépend si tu es en 4.0.x ou 4.x je crois que ça changeait déjà pas mal.
On a eu :
- le type DECIMAL qui peut ne plus contenir autant de données, car avant l'octet pour le symbole +/- pouvait être utilisé pour stocker un nombre
- les jointures : avec un LEFT JOIN, la table concernée doit être la dernière de la clause FROM

Et plus généralement : http://dev.mysql.com/doc/refman/5.0/fr/news-5-0-x.html

Merci, je vais regarder ça plus en profondeur

Pour ceux que ça intéresse, je viens de trouver une info super importante (enfin, à mon goût).

Avec MySQL 4, si vous avez un champ non signé auquel vous soustrayez une valeur plus grand que la valeur déjà dans le champ, cette valeur deviendra 0.
Alors que sous MySQL 5, cette valeur prendra taille_max.

Exemple, vous avez un champ int(11) "nombre" non signé qui vaut 4.

Sous MySQL 4, si vous faites UPDATE SET nombre = nombre - 5; alors nombre vaudra 0.

Sous MySQL 5, la valeur prendra 4294967295.

Imaginez les bug...