Laravel: Chaîne de données, tronqué à droite: 1406 Données trop long pour la colonne

J'ai une table avec une colonne 'hôtel'. Le projet est créé dans Laravel 5.4, j'ai donc utilisé les Migrations. 

    $table->string('hotel', 50);

C'est MYSQL de type VARCHAR (50). C'était bien, parce que quand j'étais en développement, j'ai utilisé court hotel des noms comme "HILTON NEW YORK 5"*.

Le projet est maintenant sur la production et le client a demandé pourquoi ils ne peuvent pas l'entrée de longue hôtel noms. Je l'ai testé avec une telle maquette nom de l'hôtel que "de Long long long long long long long long long et à très très très long nom de l'hôtel 5 étoiles"

Il m'a donné une erreur:

"SQLSTATE[22001]: Chaîne de données, tronqué à droite: 1406 Données trop long pour
la colonne 'hôtel' à la ligne 1"

J'ai ouvert la base de données dans ma Suite Pro et il a changé

  • première VARCHAR (255)
  • puis-TEXTE

Après chaque changement je l'ai testé avec le même "de Long long long long long long long long long et à très très très long nom de l'hôtel 5 commence" et obtenir le même message d'erreur (voir ci-dessus).

J'ai vérifié que le type de la colonne avec 

SHOW FIELDS FROM table_name

et il m'a donné

Champ | Type

hôtel | texte

de sorte que le type du champ est "texte" en effet (65 535 caractères).

C'est peut-être en quelque sorte lié avec Laravel fichier de Migration (voir ci-dessus) où j'ai mis VARCHAR (50), dans le début? Mais je ne peux pas ré-exécuter la migration sur la production, parce que la table contient des données maintenant.

Serais reconnaissant de toute aide.

Mise à JOUR:
J'ai découvert qu'en fait, il enregistre ce long nom de l'hôtel dans la DB. Mais l'utilisateur obtient toujours cette fâcheuse erreur à chaque fois après la soumission du formulaire...

  • Vous pouvez certainement créer une migration de modifier le type de champ. Tant que c'est quelque chose de semblable, il ne devrait pas être un problème.
  • Comme toujours, l'essayer sur votre copie locale, juste au cas où, mais je ne vois pas pourquoi ça ne marcherait pas.
  • Salut, les gars. Je vous remercie. J'ai créé une nouvelle migration comme Alexey a expliqué dans sa réponse ci-dessous et il a couru (locale), mais l'erreur est toujours s'affiche chaque fois que le formulaire est soumis....:(
InformationsquelleAutor Sergej Fomin | 2018-01-27
  1. 9

    Vous avez besoin pour créer une nouvelle migration, l'enregistrer avec composer du de commande et exécutez php artisan migrate commande pour changer le type de la colonne:

    Schema::table('the_table_name', function (Blueprint $table) {
    $table->string('hotel', 255)->change();
});
    • Salut, Alexey. Comment puis-je exécuter une migration sur le serveur sans perdre toutes les entrées de données.
    • C'est ce que les migrations pour le. Si vous allez ajouter une nouvelle migration pour changer de type de colonne et exécuter php artisan migrate de commande, aucune donnée ne sera perdue. Mais on dirait que vous êtes nouveau à cela, je vous recommande vraiment de vous entraîner sur la machine locale d'abord et à la sauvegarde des données.
    • 1) dois-je écrire quelque chose à la " fonction publique vers le bas(){ } dans le fichier de migration? 2) a essayé d'exécuter une migration et a obtenu une erreur "Modification des colonnes de la table "tours" exige la Doctrine DBAL; installer "doctrine/dbal". vais l'installer et l'exécuter sur le serveur local.
    • Oui, vous devez installer le paquet. Aussi, vous devez modifier la colonne dans up() méthode et dans down() vous devez le modifier en retour il l'état où il est maintenant. Le down() méthode est exécutée lorsque vous exécutez le php artisan migrate:rollback de commande.
    • "dans le bas() vous devez le modifier en arrière le stat c'est maintenant" - n'a pas... est-ce que votre réponse suggèrent de CRÉER un NOUVEAU fichier de migration ou de mise à jour de celui que j'avais dans mon projet avant de cette table? (si nouveau, je ne vois rien dans le bas() ....
    • Puisque vous avez de vivre DB avec des données réelles, vous devez créer une nouvelle migration pour cette.
    • Je viens de le tester en local. Le type de colonne changé de type VARCHAR (255), mais j'obtiens toujours la même erreur lors de la soumission d'un long nom de l'hôtel (93 caractères dans le dernier test)
    • Espérons que vous revenez à ce sujet:)
    • sonne comme il est lié à MySQL réglages du moteur, je ne pense pas que je vais être en mesure d'aider avec cela.
    • Votre réponse n'travail, merci à vous. C'était une autre table nommée 'previous_tours' où 'hôtel' domaine a également été ré-organisé de la même manière.

    InformationsquelleAutor Alexey Mezenin
  2. 4

    Sur votre développement local, essayez de changer le type de colonne:

    $table->longText('columnName')

    à partir de votre fichier de migration. Qui a résolu pour moi. Mais si vous avez suivi en direct, puis créer une nouvelle migration comme Alexey l'a proposé et ensuite utiliser longText() type de colonne.

    • $table->text ("nomcolonne") devrait être suffisant pour la plupart des cas
    • Le longText() contient beaucoup de données de texte(). Donc, il sait qu'il va avoir affaire à une très grande taille de texte, longText() va faire le travail.
    InformationsquelleAutor JDK Ben
  3. 1

    changer le type de la colonne destring à text.

    Puis exécutez une migrer d'actualisation à l'aide de php artisan migrate:refesh

    • Pourquoi serait-ce changement de type d'aide? OP mentionné "j'ai ouvert la base de données dans ma Suite Pro et il a changé d'abord à VARCHAR (255), puis à TEXTE Après chaque changement je l'ai testé avec le même "de Long long long long long long long long long et à très très très long nom de l'hôtel 5 commence" et obtenir le même message d'erreur (voir ci-dessus)."
    InformationsquelleAutor Pramodya Abeysinghe
  4. 0

    Changement de la colonne de type de données de chaîne de texte et de ne pas donner de longueur.

    InformationsquelleAutor Abi Raj Nijanandi