Errore MySQL 1215: impossibile aggiungere il vincolo di chiave esterna

Sto cercando di inoltrare il mio nuovo schema sul mio server db, ma non riesco a capire perché sto ricevendo questo errore. Ho provato a cercare la risposta qui, ma tutto quello che ho trovato ha detto di impostare il motore db su Innodb o di assicurarmi che le chiavi che sto cercando di usare come chiave esterna siano chiavi primarie nelle loro tabelle . Ho fatto entrambe queste cose, se non sbaglio. Qualche altro aiuto che voi ragazzi potreste offrire?

Executing SQL script in server

ERROR: Error 1215: Cannot add foreign key constraint

-- -----------------------------------------------------
-- Table `Alternative_Pathways`.`Clients_has_Staff`
-- -----------------------------------------------------

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients_has_Staff` (
  `Clients_Case_Number` INT NOT NULL ,
  `Staff_Emp_ID` INT NOT NULL ,
  PRIMARY KEY (`Clients_Case_Number`, `Staff_Emp_ID`) ,
  INDEX `fk_Clients_has_Staff_Staff1_idx` (`Staff_Emp_ID` ASC) ,
  INDEX `fk_Clients_has_Staff_Clients_idx` (`Clients_Case_Number` ASC) ,
  CONSTRAINT `fk_Clients_has_Staff_Clients`
    FOREIGN KEY (`Clients_Case_Number` )
    REFERENCES `Alternative_Pathways`.`Clients` (`Case_Number` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Clients_has_Staff_Staff1`
    FOREIGN KEY (`Staff_Emp_ID` )
    REFERENCES `Alternative_Pathways`.`Staff` (`Emp_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB

Esecuzione dello script SQL terminata: istruzioni: 7 riuscite, 1 non riuscita

Ecco l'SQL per le tabelle principali.

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients` (
  `Case_Number` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  `Address` CHAR(50) NULL ,
  `Phone_Number` INT(10) NULL ,
  PRIMARY KEY (`Case_Number`) )
ENGINE = InnoDB

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Staff` (
  `Emp_ID` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  PRIMARY KEY (`Emp_ID`) )
ENGINE = InnoDB

Immagino che Clients.Case_Numbere / o Staff.Emp_IDnon siano esattamente lo stesso tipo di dati di Clients_has_Staff.Clients_Case_Numbere Clients_has_Staff.Staff_Emp_ID.

Forse le colonne nelle tabelle principali sono INT UNSIGNED?

Devono essere esattamente dello stesso tipo di dati in entrambe le tabelle.

Motivi per cui potresti ricevere un errore di vincolo di chiave esterna:

1. InnoDB non viene utilizzato come motore su tutte le tabelle.
2. Stai tentando di fare riferimento a una chiave inesistente nella tabella di destinazione. Assicurati che sia una chiave sull'altra tabella (può essere una chiave primaria o unica)
3. I tipi di colonne non sono gli stessi (eccezione è la colonna nella tabella di riferimento può essere nullable).
4. Se PK / FK è un varchar, assicurarsi che le regole di confronto siano le stesse per entrambi.

Aggiornare:

5. Uno dei motivi potrebbe anche essere che la colonna che stai utilizzando ON DELETE SET NULLnon è definita come nulla. Quindi assicurati che la colonna sia impostata come predefinita null.

Dai un'occhiata a questi.

Per altri lo stesso errore potrebbe non essere sempre dovuto a una mancata corrispondenza del tipo di colonna, è possibile trovare ulteriori informazioni su un errore della chiave foriegn mysql inviando il comando

SHOW ENGINE INNODB STATUS;

potresti trovare un errore nella parte superiore del messaggio stampato in qualche modo

Impossibile trovare un indice nella tabella referenziata in cui le colonne referenziate vengono visualizzate come prime colonne o i tipi di colonna nella tabella e la tabella referenziata non corrispondono per il vincolo.

L'errore 1215 è fastidioso. La risposta di Explosion Pill copre le basi. Vuoi assicurarti di iniziare da lì. Tuttavia, ci sono più, molto più sottili casi da tenere in considerazione:

Ad esempio, quando si tenta di collegare TASTI PRIMARI di tabelle diverse, assicurarsi di fornire opzioni ON UPDATEe ON DELETEopzioni appropriate . Per esempio:

...
PRIMARY KEY (`id`),
FOREIGN KEY (`id`) REFERENCES `t` (`other_id`) ON DELETE SET NULL
....

non volerà, perché i PRIMARY KEY (come id) non possono esserlo NULL.

Sono sicuro che ci sono ancora più problemi allo stesso modo sottili quando si aggiungono questo tipo di vincoli, motivo per cui quando si incontrano errori di vincolo, assicurarsi sempre che i vincoli e le loro implicazioni abbiano senso nel proprio contesto attuale. Buona fortuna con il tuo errore 1215!

Controllare le regole di confronto della tabella, utilizzando SHOW TABLE STATUSè possibile controllare le informazioni sulle tabelle, incluso il confronto.

Entrambe le tabelle devono avere le stesse regole di confronto.

Mi è successo.

Nel mio caso, avevo eliminato una tabella usando SET FOREIGN_KEY_CHECKS=0, quindi SET FOREIGN_KEY_CHECKS=1dopo. Quando sono andato a ricaricare il tavolo, ho avuto error 1215. Il problema era che c'era un'altra tabella nel database che aveva una chiave esterna per la tabella che avevo cancellato e che stava ricaricando. Parte del processo di ricaricamento ha comportato la modifica di un tipo di dati per uno dei campi, il che ha reso non valida la chiave esterna dall'altra tabella, attivando così error 1215. Ho risolto il problema rilasciando e ricaricando l'altra tabella con il nuovo tipo di dati per il campo interessato.

Ho avuto lo stesso errore durante il tentativo di aggiungere un fk. Nel mio caso il problema è stato causato dal PK della tabella FK che è stato contrassegnato come non firmato.

Si è verificato un errore con "Errore 1215: impossibile aggiungere il vincolo di chiave esterna" durante l'utilizzo di Laravel 4, in particolare con i generatori Laravel 4 di JeffreyWay.

In Laravel 4, è possibile utilizzare i generatori di JeffreyWay per generare file di migrazione per creare tabelle una per una, il che significa che ogni file di migrazione genera una tabella. Devi essere consapevole del fatto che ogni file di migrazione viene generato con un timestamp nel nome del file, che dà un ordine ai file. L'ordine di generazione è anche l'ordine dell'operazione di migrazione quando si attiva il comando CLI Artisan "php artisan migrate". Pertanto, se un file richiede un vincolo di chiave esterna che fa riferimento a una chiave che verrà, ma non ancora, generata in un secondo file, viene generato l'errore 1215. In tal caso, ciò che devi fare è regolare l'ordine di generazione dei file di migrazione. Genera nuovi file nell'ordine corretto, copia il contenuto, quindi elimina i vecchi file disordinati.

ho avuto lo stesso problema, la mia soluzione:

Prima:

CREATE TABLE EMPRES
( NoFilm smallint NOT NULL

  PRIMARY KEY (NoFilm)

  FOREIGN KEY (NoFilm) REFERENCES cassettes

);

Soluzione:

CREATE TABLE EMPRES
(NoFilm smallint NOT NULL REFERENCES cassettes,

 PRIMARY KEY (NoFilm)

);

Spero sia di aiuto;)

Ho avuto lo stesso problema.
Ho risolto facendo questo:

Ho creato la seguente riga in
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

Ho scoperto questa soluzione dopo aver tentato di importare una tabella nel mio generatore di schemi. Se funziona per te, fammi sapere!

In bocca al lupo!

Felipe Tércio

Volevo solo aggiungere questo caso anche per VARCHARla relazione con le chiavi esterne. Ho trascorso l'ultima settimana a cercare di capirlo in MySQL Workbench 8.0 e alla fine sono riuscito a correggere l'errore.

Risposta breve: il set di caratteri e le regole di confronto dello schema, della tabella, della colonna, della tabella di riferimento, della colonna di riferimento e di qualsiasi altra tabella che fa riferimento alla tabella principale devono corrispondere.

Risposta lunga: avevo un tipo di dati ENUM nella mia tabella. Ho cambiato questo in VARCHARe posso ottenere i valori da una tabella di riferimento in modo da non dover modificare la tabella padre per aggiungere ulteriori opzioni. Questa relazione di chiave esterna sembrava semplice ma ho ricevuto un errore 1215. La risposta di arvind e il seguente link suggeriscono l 'uso di

SHOW ENGINE INNODB STATUS;

Usando questo comando ho ottenuto la seguente descrizione dettagliata dell'errore senza ulteriori informazioni utili

Impossibile trovare un indice nella tabella referenziata in cui le colonne referenziate vengono visualizzate come prime colonne o i tipi di colonna nella tabella e la tabella referenziata non corrispondono per il vincolo. Si noti che il tipo di archiviazione interna di ENUM e SET è cambiato nelle tabelle create con> = InnoDB-4.1.12 e che tali colonne nelle vecchie tabelle non possono essere referenziate da tali colonne nelle nuove tabelle. Fare riferimento a http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html per la corretta definizione della chiave esterna.

Dopo di che ho usato SET FOREIGN_KEY_CHECKS=0;come suggerito da Arvind Bharadwaj e il link qui :

Ciò ha dato il seguente messaggio di errore:

Codice errore: 1822. Impossibile aggiungere il vincolo di chiave esterna. Indice mancante per vincolo

A questo punto, ho "decodificato" lo schema e sono stato in grado di stabilire la relazione chiave esterna nel diagramma EER. In "ingegneria avanzata", ho ricevuto il seguente errore:

Errore 1452: impossibile aggiungere o aggiornare una riga figlio: un vincolo di chiave esterna non riesce

Quando ho inoltrato il diagramma EER su un nuovo schema, lo script SQL è stato eseguito senza problemi. Nel confrontare l'SQL generato dai tentativi di ingegnere avanzato, ho scoperto che la differenza era il set di caratteri e le regole di confronto. La tabella padre, la tabella figlio e le due colonne avevano utf8mb4set di caratteri e utf8mb4_0900_ai_ciregole di confronto, tuttavia, un'altra colonna nella tabella padre era referenziata utilizzando CHARACTER SET = utf8 , COLLATE = utf8_bin ;una tabella figlio diversa.

Per l'intero schema, ho modificato il set di caratteri e le regole di confronto per tutte le tabelle e tutte le colonne nel modo seguente:

CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

Questo ha finalmente risolto il mio problema con l'errore 1215.

Nota a margine : le regole di confronto utf8mb4_general_cifunzionano in MySQL Workbench 5.0 o versioni successive. Le regole di confronto utf8mb4_0900_ai_cifunzionano solo per MySQL Workbench 8.0 o versioni successive. Credo che uno dei motivi per cui ho avuto problemi con il set di caratteri e le regole di confronto sia dovuto all'aggiornamento di MySQL Workbench a 8.0 nel mezzo. Ecco un link che parla di più di questa raccolta.

Non riesco a trovare questo errore

CREATE TABLE RATING (

Riv_Id INT(5),
Mov_Id INT(10) DEFAULT 0,
Stars INT(5),
Rating_date DATE, 

PRIMARY KEY (Riv_Id, Mov_Id),

FOREIGN KEY (Riv_Id) REFERENCES REVIEWER(Reviewer_ID)
ON DELETE SET NULL ON UPDATE CASCADE,

FOREIGN KEY (Mov_Id) REFERENCES MOVIE(Movie_ID)
ON DELETE SET DEFAULT ON UPDATE CASCADE
)

Ciò accade anche quando il tipo di colonne non è lo stesso.

ad es. se la colonna a cui ti riferisci è UNSIGNED INT e la colonna a cui si fa riferimento è INT, viene visualizzato questo errore.

Per MySQL (INNODB) ... ottieni definizioni per le colonne che desideri collegare

SELECT * FROM information_schema.columns WHERE 
TABLE_NAME IN (tb_name','referenced_table_name') AND 
COLUMN_NAME  IN ('col_name','referenced_col_name')\G

confronta e verifica le definizioni di entrambe le colonne

stesso COLUMN_TYPE (lunghezza), stesso COLATION

potrebbe essere utile giocare come

set foreign_key_checks=0;
ALTER TABLE tb_name ADD FOREIGN KEY(col_name) REFERENCES ref_table(ref_column) ON DELETE ...
set foreign_key_checks=1;

Verifica la compatibilità della tabella. Ad esempio, se una tabella è MyISAMe l'altra è InnoDB, potresti avere questo problema.

Un altro motivo: se si utilizzano ON DELETE SET NULL tutte le colonne utilizzate nella chiave esterna, è necessario consentire valori null. Qualcun altro lo ha scoperto in questa domanda .

Da quanto ho capito non sarebbe un problema per quanto riguarda l'integrità dei dati, ma sembra che MySQL non supporti questa funzione (in 5.7).

Quando si verifica questo errore perché la tabella di riferimento utilizza il motore MyISAM, questa risposta fornisce un modo rapido per convertire il database in modo che tutte le tabelle dei modelli Django utilizzino InnoDB: https://stackoverflow.com/a/15389961/2950621

È un comando di gestione di Django chiamato convert_to_innodb.

Oh, l'ho appena preso! Era un mix di molte risposte già pubblicate (innoDB, unsigned, ecc.). Una cosa che non ho visto qui è: se il tuo FK punta su un PK, assicurati che la colonna di origine abbia un valore che abbia senso. Ad esempio, se PK è un mediumint (8), assicurarsi che la colonna di origine contenga anche un mediumint (8). Questo era parte del problema per me.

Per me erano i tipi di colonna. BigINT! = INT.

Ma poi non ha ancora funzionato.

Quindi ho controllato i motori. Assicurarsi che Table1 = InnoDB e Table = InnoDB

Ho riscontrato questo errore per un motivo completamente diverso. Ho usato MySQL Workbench 6.3 per creare il mio modello di dati (strumento fantastico). Ho notato che quando l'ordine delle colonne definito nella definizione del vincolo Chiave esterna non si adatta alla sequenza delle colonne della tabella, viene generato anche questo errore.

Mi ci sono volute circa 4 ore per provare tutto il resto ma controllarlo.

Ora tutto funziona bene e posso tornare alla programmazione. :-)

quando si tenta di creare una chiave esterna quando si utilizza la migrazione laravel

come in questo esempio:

tabella utente

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->TinyInteger('color_id')->unsigned();
        $table->foreign('color_id')->references('id')->on('colors');
        $table->timestamps();
    });
}

tabella colori

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('color');
        $table->timestamps();
    });
}

a volte le proprietà non funzionavano

[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

questo errore si è verificato perché la chiave esterna (tipo) in [tabella utente] è differita dalla chiave primaria (tipo) in [tabella colori]

Per risolvere questo problema dovrebbe cambiare la chiave primaria in [tabella colori]

$table->tinyIncrements('id');

Quando si utilizza la chiave primaria $table->Increments('id');

dovresti usare Integercome chiave esterna

    $table-> unsignedInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Quando si utilizza la chiave primaria $table->tinyIncrements('id');

dovresti usare unsignedTinyIntegercome chiave esterna

    $table-> unsignedTinyInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Quando si utilizza la chiave primaria $table->smallIncrements('id');

dovresti usare unsignedSmallIntegercome chiave esterna

    $table-> unsignedSmallInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Quando si utilizza la chiave primaria $table->mediumIncrements('id');

dovresti usare unsignedMediumIntegercome chiave esterna

    $table-> unsignedMediumInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Nel mio caso ho dovuto disabilitare i FOREIGN KEYcontrolli poiché le tabelle di origine non esistevano.

SET FOREIGN_KEY_CHECKS=0;

Sii consapevole anche dell'uso dei backquotes. In una sceneggiatura avevo la seguente dichiarazione

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user(id)`;

ma i backquotes alla fine erano falsi. Sarebbe dovuto essere:

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user`(`id`);

MySQL non dà sfortunatamente alcun dettaglio su questo errore ...

Un'altra fonte di questo errore è che hai 2 o più nomi di tabelle uguali che hanno gli stessi nomi di chiave esterna. Questo a volte accade a persone che usano software di modellazione e progettazione, come Mysql Workbench, e in seguito generano lo script dal design.

So di essere MOLTO in ritardo alla festa, ma voglio pubblicarlo qui in modo che sia elencato.

Oltre a tutti i consigli di cui sopra per assicurarsi che i campi siano definiti in modo identico e che anche i tipi di tabella abbiano le stesse regole di confronto, assicurati di non commettere l'errore da principiante nel provare a collegare campi in cui i dati nel campo CHILD non sono già nel campo GENITORE. Se hai dati nel campo BAMBINO che non hai già inserito nel campo GENITORE, ciò causerà questo errore. È un peccato che il messaggio di errore non sia un po 'più utile.

Se non si è sicuri, eseguire il backup della tabella con la chiave esterna, eliminare tutti i dati e quindi provare a creare la chiave esterna. In caso di successo, allora cosa fare!

In bocca al lupo.

Questa è una versione sottile di ciò che è già stato detto, ma nel mio caso avevo 2 database (foo e bar). Ho creato prima foo e non mi rendevo conto che faceva riferimento a una chiave esterna in bar.baz (che non era ancora stato creato). Quando ho provato a creare bar.baz (senza chiavi esterne), ho continuato a ricevere questo errore. Dopo essermi guardato intorno per un po ', ho trovato la chiave esterna in foo.

Quindi, per farla breve, se viene visualizzato questo errore, è possibile che sia presente una chiave esterna preesistente per la tabella che viene creata.

Per me, l'errore 1215 si è verificato durante l'importazione di un file di dump creato da mysqldump, che crea le tabelle in ordine alfabetico, che nel mio caso ha causato le chiavi esterne a fare riferimento alle tabelle create successivamente nel file. (Propone a questa pagina per segnalarlo: https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/ )

Dato che mysqldump ordina le tabelle in ordine alfabetico e non volevo cambiare il nome delle tabelle, ho seguito le istruzioni nella risposta di JeremyWeir in questa pagina , che afferma di mettere set FOREIGN_KEY_CHECKS = 0;in cima al file di dump e mettereSET FOREIGN_KEY_CHECKS = 1; in fondo al file di dump .

Quella soluzione ha funzionato per me.

Quindi ho provato tutte le correzioni sopra e senza fortuna. Potrei mancare l'errore nelle mie tabelle, non sono riuscito a trovare la causa e ho continuato a ricevere l'errore 1215. Quindi ho usato questa correzione.

Nel mio ambiente locale in phpMyAdmin, ho esportato i dati dalla tabella in questione. Ho selezionato il formato CSV. Mentre ero ancora in phpMyAdmin con la tabella selezionata, ho selezionato "Altro-> Opzioni". Qui ho scorrere verso il basso fino a "Copia tabella in (database.table). Seleziona" Solo struttura ". Rinomina la tabella qualcosa, forse aggiungi semplicemente la parola" copia "accanto al nome della tabella corrente. Fai clic su" Vai "Questo creerà un nuovo tabella Esporta la nuova tabella e importala sul nuovo o su un altro server. Anche qui sto usando phpMyAdmin. Una volta importata, cambia il nome della tabella con il nome originale. Seleziona la nuova tabella, seleziona import. Per il formato seleziona CSV Deseleziona "Abilita controlli chiave esterna". Seleziona "Vai". Finora tutto funziona bene.

Ho pubblicato la mia correzione sul mio blog .

Anche io ho avuto lo stesso problema. E la colpa era del marcatore "unsigned" nel tavolo PK dell'FK

Ho avuto lo stesso errore una volta. Ho semplicemente riavviato il server MySQL e risolto il problema.