Ich habe zuvor eine Benutzertabelle erstellt. Jetzt habe ich eine neue Migration erstellt, um eine neue Buchtabelle in meinem Schema zu erstellen. Wenn ich versuche, den Befehl auszuführen
php artisan migrate
Es zeigt:
[Illuminate\Database\QueryException]
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' alre
ady exists (SQL: create table `users` (`id` int unsigned not null auto_incr
ement primary key, `username` varchar(255) not null, `email` varchar(255) n
ot null, `password` varchar(255) not null, `created_at` timestamp default 0
not null, `updated_at` timestamp default 0 not null) default character set
utf8 collate utf8_unicode_ci)
Hier ist meine neue Migrationstabelle:
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateBooksTable extends Migration {
public function up()
{
Schema::create('books', function(Blueprint $table)
{
$table->increments('id');
$table->string('name');
$table->string('auther');
$table->string('area');
$table->timestamps();
});
}
public function down()
{
Schema::drop('books');
}
}
Wie kann ich den Fehler beseitigen?
Du musst rennen
php artisan migrate:rollback
wenn dies ebenfalls fehlschlägt, gehen Sie einfach in die Tabelle und löschen Sie alle Tabellen, die Sie möglicherweise tun müssen, da Ihre Migrationstabelle anscheinend durcheinander gerät oder Ihre Benutzertabelle beim Ausführen eines vorherigen Rollbacks die Tabelle nicht gelöscht hat.
BEARBEITEN:
Der Grund dafür ist, dass Sie zuvor einen Rollback ausgeführt haben und der Code fehlerhaft war oder die Tabelle nicht gelöscht hat. Dies führt jedoch immer noch zu einer Verwirrung der Laravel-Migrationstabelle, und Sie haben jetzt keine Informationen darüber, wie Sie die Benutzertabelle nach oben verschieben können. Die Benutzertabelle existiert jedoch bereits und dieser Fehler wird geworfen.
In v5.x könnten Sie immer noch vor dem Problem stehen. Versuchen Sie daher zunächst, die verknüpfte Tabelle manuell mit zu löschen
php artisan tinker
Dann
Schema::drop('books')
(und mit q
beenden)
Jetzt können Sie erfolgreich php artisan migrate:rollback
Und php artisan migrate
Ausführen.
Wenn dies wiederholt vorkommt, sollten Sie überprüfen, ob die down()
-Methode in Ihrer Migration den richtigen Tabellennamen anzeigt. (Kann ein Gotcha sein, wenn Sie Ihre Tabellennamen geändert haben.)
Ich hatte das gleiche Problem. Der Grund ist, dass Ihr Dateiname in Migrationsordner nicht mit Name der Migration in Ihrer Datenbank übereinstimmt (siehe Migrationstabelle). Sie sollten gleich sein.
U kann vor Schema::create('books', function(Blueprint $table)
folgenden Code Schema::drop('books');
einfügen
EDIT: (für Laravel)
Kommen Sie einfach durch dieses Problem, während Sie an einem Projekt in Laravel arbeiten. Meine Tische waren durcheinander und mussten regelmäßig in Spalten geändert werden. Sobald die Tische dort waren, konnte ich php artisan migrate
nicht mehr ausführen.
Ich habe folgendes getan, um das Problem loszuwerden-
$ composer dump-autoload -o
php artisan migrate
Vorheriger Kommentar zu Lumen
[Nun, ziemlich spät zur Party (und möglicherweise eine andere Party als die, nach der ich gesucht habe). Ich schlug mit dem Kopf, schrie laut auf und fand durch die Anmut eines grauen Schädels gerade eine Lösung.]
Ich entwickle eine beruhigende App mit Lumen und bin neu dabei. Dies ist mein erstes Projekt/Experiment mit Laraval und Lumen. Meine Abhängigkeiten
"require": {
"php": ">=5.6.4",
"laravel/Lumen-framework": "5.4.*",
"vlucas/phpdotenv": "~2.2",
"barryvdh/laravel-cors": "^0.8.6",
"league/fractal": "^0.13.0"
},
"require-dev": {
"fzaninotto/faker": "~1.4",
"phpunit/phpunit": "~5.0",
"mockery/mockery": "~0.9.4"
}
Jedenfalls war bis gestern Nacht alles in Ordnung, aber plötzlich phpunit
begann sich über einen bereits vorhandenen Tisch zu beschweren.
Caused by
PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'items' already exists
Duh! Items
Tabelle sollte in der Datenbank vorhanden sein, oder wie soll ich Artikel speichern?
Jedenfalls bestand das Problem nur in den Testklassen, aber seltsamerweise nicht im Browser (ich habe mit Chrome, Firefox und Postman die Kopfzeile geändert). Ich erhielt wie erwartet JSON-Antworten mit Daten.
Ich habe die Datenbank gelöscht und mit vielen Variablen migrate
, refresh
, rollback
neu erstellt. Alles war gut, aber in phpunit
.
Aus Verzweiflung entfernte ich meine Migrationsdateien (natürlich nahm ich zuerst ein Backup an) und drückte dann im Terminal auf phpunit
. Das Gleiche noch einmal.
Plötzlich fiel mir ein, dass ich zu Testzwecken einen anderen Datenbanknamen in die phpunit.xml
-Datei geschrieben habe. Ich habe diese Datenbank überprüft und weißt du was? Es gab eine Tabelle mit dem Namen items
. Ich habe diese Tabelle manuell entfernt, phpunit
ausgeführt, alles hat gut funktioniert.
Ich dokumentiere meine Erfahrung nur für zukünftige Referenzen und hoffe, dass dies in Zukunft jemandem helfen kann.
Ich habe einen wirklich schlechten Code von jemandem geerbt, der keine Migrationen verwendet hat! ?, fügte die Dateinamen daher manuell in die Migrationen ein und vergaß das Entfernen der nachfolgenden .php
Das verursachte den Fehler "Tabelle existiert" trotz der Übereinstimmung von Dateiname und Migration.
2018_05_07_142737_create_users_table.php - FALSCH 2018_05_07_142737_create_users_table - CORRECT
Sie können .__ verwenden. php artisan migrate:fresh
um alle Tabellen zu löschen und dann zu migrieren . Hoffe, es hilft
Ich hatte ein ähnliches Problem, nachdem ich mich mit Fremdschlüsseleinschränkungen beschäftigt hatte. Einer meiner Tabellen (Notizen) war verschwunden, und einer kam immer wieder zurück (Aufgaben), auch nachdem er in MySQL abgelegt wurde. Dadurch konnte ich nicht ausgeführt werden: php artisan migrate/refresh/reset
, wodurch die oben genannte 42s01-Ausnahme erzeugt wurde.
Was ich getan habe, um es zu lösen, war ssh in vagrant, dann geh in MySQL (vagrant ssh, mysql -u Homestead -p secret
) und dann: DROP DATABASE Homestead; Then CREATE DATABASE Homestead; Then exit mysql and run:
php Handwerker migrieren '.
Offensichtlich funktioniert diese Lösung nicht für Benutzer, die kein Vagabund/Homestead verwenden. Dies ist zwar kein ordentlicher Arbeitsablauf, aber mein Problem wurde gelöst, das dem oben genannten sehr ähnlich sieht.
Ich denke, meine Antwort wird mehr helfen. Ich stand auch diesem Fehler gegenüber. Dann löschte ich eine bestimmte Migrationsdatei und versuchte sie von PHP-Handwerker neu zu erstellen.
Aber bevor ich diesen Punkt vor 1 oder 2 Tagen erlebte, als ich mir Laracast-Videos über Migation angesehen hatte, dachte ich über Rollback nach und migriere bestimmte Tabellen. Aus irgendeinem Grund habe ich eine bestimmte Migrationsdatei gelöscht und versucht, sie neu zu erstellen. Dabei habe ich Folgendes erhalten:
[ErrorException] include (C:\wamp64\www\laraveldeneme\vendor\composer /../../ database/migrations/2017_01_09_082715_create_articles_table.php): Der Stream konnte nicht geöffnet werden: Keine solche Datei oder ein solches Verzeichnis
Wenn ich diese Datei überprüfe, sah ich die Zeile unterhalb von array in der Datei autoload_classmap.php:
'CreateArticlesTable' => $ baseDir. '/ Database/migrations/2017_01_09_083946_create_articles_table.php',
Nach dem Rollback oder Löschen einer Migrationsdatei verbleibt der mit der Migrationsdatei verknüpfte Datensatz in der autoload_classmap.php-Datei des Composers.
Um dieses Problem zu lösen, habe ich den Composer-Befehl von irgendwo her gefunden, an den ich mich nicht erinnern kann.
composer dump-autoload
Wenn ich diesen Code umrandete, ist die Zeile für die gelöschte Migrationsdatei nicht mehr vorhanden. Dann lief ich:
php artisan make:migration create_articles_table --create=articles
Schließlich habe ich meine Migrationsdatei mit demselben Namen neu erstellt
gehen Sie zu phpmyadmin, löschen Sie die Datenbank, die Sie für laravel erstellt haben, erstellen Sie sie dann erneut, gehen Sie zu cmd (wenn Sie Windows verwenden) und geben Sie php artisan migrate ein
Überprüfen Sie Ihre Tabellen nach dem Rollback, und stellen Sie sicher, dass sie gelöscht werden.
Wenn ein Problem auftritt, löschen Sie Tabellen manuell aus der Datenbankanwendung wie phpmyadmin (ich verwende sequel pro for mac).
Korrigieren Sie Ihre Down-Methoden bei der Migration.
Hinweis: Führen Sie ein Rollback durch und migrieren Sie dann nicht. Migrate nicht verwenden: Aktualisieren, um festzustellen, wo der Fehler war.
Danach können Sie mit neuer Datenbank zum Testen testen. erkennen, wo das Problem liegt.
Lesen Sie auch diese Frage
php artisan migrate:rollback
Lösung überprüfen: Laravel Official Solution
Wie im Migrations guide beschrieben, müssen Sie lediglich die Datei app\Providers\AppServiceProvider.php bearbeiten und in der Boot-Methode eine Standardzeichenfolge festlegen:
use Illuminate\Support\Facades\Schema;
public function boot()
{
Schema::defaultStringLength(191);
}
Nach dem obigen Befehl müssen Sie alle verbleibenden Tabellen manuell löschen und anschließend den Befehl ausführen:
php artisan migrate:fresh
Sie können alle Tabellen löschen, dies ist jedoch keine gute Praxis. Versuchen Sie stattdessen diesen Befehl
php artisan migrate:fresh
Stellen Sie sicher, dass Sie die Namenskonvention korrekt verwenden. Ich habe dies in Version 5.7 getestet. Es ist wichtig, dass Sie diesen Befehl nicht versuchen, wenn sich Ihre Site auf dem Server befindet, da dadurch alle Informationen verworfen werden.
Löschen Sie zuerst die Benutzertabelle in der Datenbank. Wechseln Sie dann zur Eingabeaufforderung, und geben Sie Folgendes ein
php artisan migrate
alle Sätze. Ich denke, diese Antwort hilft.
Fügen Sie dies zu AppServiceProvider.php hinzu
use Illuminate\Support\Facades\Schema;
public function boot() {
Schema::defaultStringLength(191);
}
Löschen Sie alle Tabellen manuell beim phpmyadmin.
Wechseln Sie zu jeder Migrationsdatei unter Datenbank/Migrationen. Suchen und entfernen Sie diese 2 Codes:
a) -> index () (gefunden bei 2014_10_12_100000_create_password_resets_table.php in Zeile 17)
b) -> unique () (gefunden bei 2014_10_12_000000_create_users_table.php in Zeile 19)
Führen Sie "PHP Handwerker migrieren" aus.
Erledigt.
Ich denke, das passiert, weil die letzte Laravel-Klasse (am 12. Februar 2018) die Funktion -> index () und -> unique () entfernt hat.
Ich habe Ihr Problem gelöst, indem Sie die "Benutzer" -Tabelle in sequel-pro gelöscht haben (in meiner Benutzertabelle sind keine Daten vorhanden). Anschließend können Sie php artisan migrate
ausführen.
Hier sind vor und nach Screenshots
bevor ich den user table user lösche
nachdem ich die Tabelle user gelöscht habe
2014_10_12_100000_create_password_resets_table.php
Schema::create('password_resets', function (Blueprint $table) {
$table->string('email');
$table->string('token');
$table->timestamp('created_at')->nullable();
});
2014_10_12_000000_create_users_table.php
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->string('email');
$table->string('password');
$table->rememberToken();
$table->timestamps();
});
Die Antwort ist sehr einfach:
Erstellen Sie zuerst eine Sicherungskopie des Ordners bootstrap/cache.
Löschen Sie dann alle Dateien aus dem Bootstrap/Cache-Ordner.
Führen Sie nun Folgendes aus:
php artisan migrate
Ich stand auch vor dem gleichen Problem, ich folgte dem gleichen Prozess, aber mein Problem wurde nicht gelöst, also versuche ich etwas anderes. Ich habe die Tabellen aus meiner Datenbank gelöscht und die Header-Datei verwendet
use Illuminate\Support\Facades\Schema;
und erhöhen Sie die Standard-Stringlänge in der Boot-Methode, um Folgendes hinzuzufügen: -
Schema::defaultStringLength(191);
dann wieder umziehen. Problem ist gelöst, alle Tabellen werden in der Datenbank erstellt.
In Laravel 5.4, Wenn Sie dieses Problem haben. Überprüfe diesen Link
-oder-
Gehen Sie zu dieser Seite in app/Providers/AppServiceProvider.php Und fügen Sie den unten stehenden Code hinzu
use Illuminate\Support\Facades\Schema;
public function boot()
{
Schema::defaultStringLength(191);
}
Ich hatte das gleiche Problem, das Problem liegt in dem Namen, der in den Tabellenmigrationen in der Datenbank gespeichert ist, da in meiner Datenbank 2017_10_18_200000_name
und in den Dateien 2016_10_18_200000_name
nach Änderung des Namens der funktionierenden Datei vorhanden ist.
DANGER- Die meisten dieser Antworten löschen Ihre Datenbank und werden für den Produktionsbetrieb nicht empfohlen.
Es ist klar, dass es viele "Lösungen" für dieses Problem gibt, aber all diese Lösungen, die ich durchgelesen habe, sind sehr destruktive Lösungen und keine von ihnen funktioniert für eine Produktionsdatenbank. Aufgrund der Anzahl der Lösungen scheint es auch verschiedene Ursachen für diesen Fehler zu geben.
Mein Fehler wurde durch einen fehlenden Eintrag in meiner Migrationstabelle verursacht. Ich weiß nicht genau, wie es passiert ist, aber als ich es wieder hinzufügte, erhielt ich den Fehler nicht mehr.
AppServiceProvider.php bearbeiten finden Sie unter app/Providers/AppServiceProvider.php und fügen Sie hinzu
use Illuminate\Support\Facades\Schema;
public function boot()
{
Schema::defaultStringLength(191);
}
Dann renne
composer update
An Ihrem Terminal ... Es hat mir geholfen, vielleicht wird es auch für Sie funktionieren.
Löschen Sie alle Datenbanktabellen und führen Sie diese Zeile in Ihrem Projektpfad über CMD aus
php artisan migrate
Ich hatte auch diese Ausgabe, diese Antwort fand ich gerade auf einem Youtube Video . Nicht sicher, ob es ideal ist, aber es ist das Beste, was ich je gesehen habe.
Scheint die AppServiceProvider.php
-Datei des Anbieterverzeichnisses, indem dem Schema eine Länge zugewiesen wird. In diesem Fall 191
. Funktioniert wie Magie. Screenshot . Er lief dann: php artisan migrate:fresh
. Hoffe das klappt.
Überprüfen Sie zunächst die Tabelle migrations in Ihrer Datenbank und stellen Sie sicher, dass Ihre Migrationsdateien im Datenbankordner Ihres Projekts mit diesen Tabellendaten übereinstimmen. Wenn Sie manuell Migrationsdateien erstellen, tritt manchmal dieser Fehler auf, wenn Sie den Befehl migrate in composer ausführen.
Sie können immer nach der Existenz einer Tabelle suchen, bevor Sie sie erstellen.
if(!Schema::hasTable('books')){
Schema::create('books', function(Blueprint $table)
{
$table->increments('id');
$table->string('name');
$table->string('auther');
$table->string('area');
$table->timestamps();
});
}
Das Erstellen einer Datenbank dauert buchstäblich Sekunden . Exportieren Sie Ihre aktuelle Datenbank, falls sensible Daten vorhanden sind . Überprüfen Sie Ihre Migrationen und beseitigen Sie alle falschen Methoden php artisan migrate Dann können Sie die zuvor in der Datenbank vorhandenen Daten zurückgeben . Works !!!
Lösung: Laravel Migrationstabelle existiert bereits ... || Es funktioniert in Laravel 5.8 also
app\Providers\AppServiceProvider.php-Datei
und innerhalb der Boot-Methode eine Standard-String-Länge festlegen:
public function boot()
{
Schema::defaultStringLength(191);
}
und offen
config\database.php
'charset' =>'utf8mb4',
'collation' =>'utf8mb4_unicode_ci',
und ändere es in
'charset' =>'utf8',
'collation' =>'utf8_unicode_ci',
speichern Sie alle Dateien und rufen Sie die Eingabeaufforderung auf
php artisan migrate