Discussion :

[4rocky4]

Bonjour tout le monde,

Je souhaite migrer une base de données de SQL Server vers MySQL, pour cela, j'utilise l'outil MySQL Migration Toolkit.

Lors de la création des tables, j'ai cette erreur pour une table :

Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

Dans la table qui provoque cette erreur, j'ai :
6 nvarchar(4000)
1 varchar(4000)
4 varchar(30)
2 varchar(64)
2 varchar(8)
Et 4 ou 5 champs de type entier.

Si je supprime n'importe quel nvarchar(4000), la migration se fait sans erreur.

Pouvez vous m'expliquez cette situation ?

[michel.bosseaux]

pour ce que j'en sais, nvarchar correspond à des caractères unicode et donc prend physiquement le double de place de ce que tu indiques.

Donc en effet, quand on calcule, tu dépasses les 64ko pour un enregistrement.

Si tu indiques varchar(max) au lieu d'une taille, ou si tu déclares text, tu définis des champs qui ne sont pas stockés dans les 64ko de ton enregistrement, mais en dehors, dans un dictionnaire de chaînes.
Normal donc qu'avec text, cela fonctionne mieux dans ton cas.

[4rocky4]

Désolé, j'viens de refaire un test ...
Si je remplace un nvarchar(4000) par test, la table ne se créer pas non plus ...
Si après je supprime le champ que je viens de remplacer, la table se créer.

Edit : J'pense que MySQL avait planté. Le fait d'enlever un nvarchar ça à l'air de mieux marcher.

[4rocky4]

Donc en effet, quand on calcule, tu dépasses les 64ko pour un enregistrement.

Un enregistrement dans une table ne doit pas dépasser 64ko ?
Pourquoi le fait de mettre text résoud le problème ?
Et ya une grosse différence entre nvarchar et text ?

[michel.bosseaux]

Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs
?

Tu remarqueras que le 64ko, et le fait que passer en text résoud le problème, sont deux informations qui se trouvent dans le message d'erreur que je reprend de ton premier message.
Après, je t'ai expliqué (mal il semble) que quand tu définis un champ comme "text", il n'est pas stocké dans ton enregistrement, mais dans un emplacement à part réservé aux chaînes.

[4rocky4]

Merci pour cette réponse. Cependant je ne vois pas que je dépasse les 64ko ...

Est-il possible de m'expliquer comment s'effectue ce calcul car je ne les atteins pas lorsque je fais le calcul

[Sivrît]

6*4000+4000+4*30+2*64+2*8 = 28264 caractères. Si c'est de l'utf-8, chacun peut prendre 3 octets. Donc sans compter les entiers, ça fait déjà 84792o, soit potentiellement bien plus que les 64ko d'une page de données de MySQL.

[michel.bosseaux]

les nvarchars sont codés en unicode donc compte pour 2, voir +, caractères. C'est donc au moins 48000 rien que pour les nvarchar (ce qui, je te l'accorde, ne suffirait pas à te faire déborder les 64ko, donc il faut supposer que sivrit a vu juste et qu'ils prennent trois octets pour un, au lieu de deux)

[Sivrît]

L'utf-8 est à taille variable. Il a l'avantage d'utiliser 1 octet par caractère pour les caractères usuels (pour nous du moins), mais potentiellement 2 ou 3 pour d'autres. Pour tout ce qui est dimensionnement de tampon ou autre devant obligatoirement contenir une chaine de N caractères, il faut donc se caler sur le pire cas possible, à savoir 3 octets.

MySQL range ses enregistrements dans des pages de 64ko (au moins pour InnoDB, pour les autres moteurs j'ai un doute). Il peut y avoir plusieurs enregistrements par page, mais un enregistrement ne peut pas être fragmenté. Donc, toute table dont un enregistrement pourrait dépasser 64ko est refusée.

[4rocky4]

Très intéressant tout ça

Cependant ma base est en Latin1 (innodb) ...

[Sivrît]

Si seuls les nvarchar sont en utf-8 ça dépasse encore, mais de peu. Ça expliquerait qu'en supprimer un permette de s'en sortir.
MySQL ne semple pas connaitre le type nvarchar, donc comme michel.bosseaux le suggère, l'outil de migration doit en faire des varchar utf-8.

[4rocky4]

Y-aurait-il de la documentation sur ce sujet ?

Est-il possible de voir le charset d'un type de champ ?
Cela permettrait de voir si c'est bien de l'utf-8.

Et j'ai une autre question qui sort de MySQL mais qui reste dans le même sujet, Oracle et SQL Server ont aussi un quota pour un enregistrement ?

---------------

Il y a un truc que je trouve bizarre, je vous l'explique.
Lors de la migration, si je migre un champ de type varchar avec des valeurs qui contiennent des accents, la migration ne se fait pas, il y a une erreur.
Si je change le type varchar en nvarchar, il n'y a aucun problème.

Effectivement, dans MySQL, quoi qu'il arrive, le type est varchar, donc il doit bien avoir une différence entre les deux lors de leur migration.

Cependant, que ma base MySQL soit en UTF-8 ou en LATIN-1, ça ne change rien, il faut tout de même que le type migré avec des accents soit nvarchar.
Si ma base à l'origine est en UTF-8, le fait de migrer un varchar se ferait en UTF-8 et donc ne devrait poser aucun problème d'après ce que vous dites.

Je me trompe ?