Laravel Migration (errno: 150 "Fremdschlüsselbedingung ist falsch gebildet")

der Fremdschlüssel muss eine "unsignedBigInteger" sein und wird wie folgt repariert:

$table->unsignedBigInteger('user_id');

$table->foreign('user_id')->references('id')->on('users');

Primärschlüssel und Fremdschlüssel sollten denselben Datentyp haben .

Wenn der Primärschlüssel vorzeichenloses big_integer Verwendet, sollte der Fremdschlüssel auch vorzeichenloses big_integer Verwenden.

Falls laravel 5.8 beim Generieren einer neuen Migration standardmäßig bigIncrements verwendet (siehe dies Pull-Anfrage ), sollten Sie sicherstellen, dass Ihr foreign key ist auch big_increment oder es wird eine Fehlermeldung ausgegeben.

Tabelle users:

Schema::create('users', function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->string('name');

    ...

}

Tabelle orders:

Schema::create('orders', function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->unsignedBigInteger('user_id');

    ...

    $table->foreign('user_id')->references('id')->on('users');
}

Hoffe das hilft.

Laravel 5.8.3 enthält $table->bigIncrements('id');

ändere es in

$table->increments('id');
$table->integer('order_id')->unsigned();

Für jeden, der sich das mit laravel 5.8.x ansieht, habe ich das behoben, indem ich das geändert habe

$table->unsignedInteger('foreign_id');

dazu

$table->unsignedBigInteger('foreign_id');

Das liegt an der Verwendung von bigIncrements. Sie können stattdessen zufällige große Inkremente zu Inkrementen auf beiden Seiten der Beziehung entfernen

Überprüfen Sie die Reihenfolge Ihrer Migrationen. Wenn Ihr Migrationsbefehl versucht, die sell_shipping_labels-Tabelle vor der Orders-Tabelle zu erstellen, tritt dies bei MySQL auf. Es scheint, das Migrationsdatum zu erstellen, vom ältesten zum neuesten. Mit anderen Worten, die order_id in der Tabelle, die sie referenzieren soll, sollte vorhanden sein.

Ich bin mit dem gleichen Problem konfrontiert und ändere das Migrationsdatum.

Wenn das Problem immer noch nicht behoben ist, probieren Sie es aus. Sie müssen die letzte zugeordnete Tabelle erstellen.

Sie sollten zuerst Aufträge erstellen und anschließend die Tabelle sell_shipping_labels erstellen

Um das Problem zu beheben, sollten Sie die Migrationsdateien der Kategorien und Benutzer auf das Datum vor den Mahlzeiten umbenennen. Migrationsdatei, die die Tabelle vor den Mahlzeiten erstellt.

Ich stand heute vor dem gleichen Problem. Meine laravel Version ist 5.8.29. Ich habe das Problem folgendermaßen gelöst:

$table->bigIncrements('id'); //current table primary key and id
$table->unsignedBigInteger('user_id'); // foreigh key
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');

Hoffe das klappt.

Ich habe auch den gleichen Fehler bekommen. Was ich in users table gemacht habe, ist

$table->unsignedInteger('role_id')->default(2); table->foreign('role_id')->references('id')->on('roles')->onDelete('cascade');

Aber ich habe die Rollentabelle nach dem Erstellen der Benutzertabelle erstellt. Also habe ich das Datum der Rollenmigrationsdatei vor dem Datum der Dateinamen der Benutzer bearbeitet. So was,

2013_01_22_091213_create_roles_table.php
2014_10_12_000000_create_users_table.php

Und endlich geht es. Vielleicht bekommst du vielleicht irgendwann dieses Problem. Also habe ich es gepostet.

Ich war heute mit diesem Problem konfrontiert. Ich überprüfte alle vorgeschlagenen Lösungen, wie den referenzierten Schlüssel und den Fremdschlüssel, denselben Datentyp, dieselbe Kollatierung in der Datenbank-Engine und laravel config (database.php), die Reihenfolge der Migrationen und andere mögliche Fehler, aber keine Als letzte Lösung habe ich onUpdate- und onDelete-Einschränkungen gefunden, die zu Migrationen führten. Indem ich sie entferne, ist mein Problem gelöst.

[![enter image description here][1]][1]
public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();


        });
    }

I changed $table->bigIncrements('id') to $table->Increments('id')
For this user_id of files table become same integer type as user table field id. After this command worked.

   public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }



For the second table
 {
        Schema::create('files', function (Blueprint $table) {
            $table->increments('id');

});

            Schema::table('files', function($table) {
            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
           });
    }

1. Migrationsdateien sollten so erstellt werden, dass die übergeordnete Migration an erster Stelle steht und die Migrationsdatei den Fremdschlüssel als nächsten enthält.
2. Der Fremdschlüssel und die primäre ID in der anderen Tabelle sollten genau die gleiche Eigenschaft haben. Wenn die primäre ID Inkremente ist, machen Sie den Fremdschlüssel ganzzahlig ('xxx_id') -> unsigned ();

Ich hatte das gleiche Problem und das Problem behoben, als der Datenbanktyp auf innoDB eingestellt wurde.

Die vor der Migration erstellten Tabellen, bei denen "MyISAM aus einem Altsystem" und die migrierten Datenbanken standardmäßig innoDB sind, waren in meinem Fall ein Mix aus Tabellentypen.

Für diejenigen, deren Antwort nicht funktioniert hat:

Überprüfen Sie Ihre Tabellen-Engine. In meinem Fall habe ich auf eine MyISAM - Tabelle in einer InnoDB - Quelltabelle referenziert. Nachdem die Referenztabellen-Engine auf InnoDB umgestellt wurde, hat es funktioniert!