Ik probeer een .SQL-bestand te importeren en het falen op het maken van tabellen.
Hier is de query die faalt:
CREATE TABLE `data` (
`id` int(10) unsigned NOT NULL,
`name` varchar(100) NOT NULL,
`value` varchar(15) NOT NULL,
UNIQUE KEY `id` (`id`,`name`),
CONSTRAINT `data_ibfk_1` FOREIGN KEY (`id`) REFERENCES `keywords` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Ik heb de .sql uit dezelfde database geëxporteerd, ik heb alle tabellen laten vallen en nu probeer ik het te importeren, waarom faalt het?
MySQL: kan geen tabel maken ‘./dbname/data.frm’ (errno: 150)
Antwoord 1, Autoriteit 100%
Vanaf de MySQL – Documentatie Buitenlandse Key Constraints :
Als u een tabel opnieuw maakt die is laten vallen, moet het een definitie hebben die voldoet aan de buitenlandse key-beperkingen die het verwijzen. Het moet de juiste kolomnamen en -typen hebben en het moet indexen hebben op de verwijderde toetsen, zoals eerder vermeld. Als deze niet tevreden zijn, retourneert MySQL de fout 1005 en verwijst naar Fout 150 in het foutbericht, wat betekent dat een buitenlandse sleuteldienst niet correct is gevormd. Evenzo, als een Alter-tabel mislukt als gevolg van fout 150, dit betekent dat een buitenlandse sleuteldefinitie verkeerd zou worden gevormd voor de gewijzigde tabel.
Antwoord 2, Autoriteit 59%
FOUT 150 betekent dat u een probleem hebt met uw buitenlandse sleutel. Mogelijk is de sleutel op de buitenlandse tafel niet exact hetzelfde type?
Antwoord 3, Autoriteit 40%
U kunt de daadwerkelijke foutmelding krijgen door SHOW ENGINE INNODB STATUS;uit te voeren en vervolgens te zoeken naar LATEST FOREIGN KEY ERRORin de uitvoer.
Bron: antwoord van een andere gebruiker in een vergelijkbare vraag
Antwoord 4, autoriteit 18%
Gegevenstypen moeten exact overeenkomen. Als je te maken hebt met varchar-typen, moeten de tabellen dezelfde sortering gebruiken.
Antwoord 5, autoriteit 15%
Ik denk dat al deze antwoorden, hoewel correct, misleidend zijn voor de vraag.
Het eigenlijke antwoord is dit voordat u een herstel start, als u een dumpbestand herstelt met externe sleutels:
SET FOREIGN_KEY_CHECKS=0;
omdat het herstel natuurlijk enige beperkingen zal creëren voordat de vreemde tabel zelfs maar bestaat.
Antwoord 6, autoriteit 14%
In sommige gevallen kunt u deze foutmelding tegenkomen als er verschillende engines zijn tussen de gerelateerde tabellen. Een tabel kan bijvoorbeeld InnoDB gebruiken terwijl de andere MyISAM gebruikt. Beide moeten hetzelfde zijn
Antwoord 7, autoriteit 6%
Foutnr. 150 betekent een storing in een externe sleutelbeperking. Waarschijnlijk maakt u deze tabel vóór de tabel waarvan de externe sleutel afhankelijk is (tabel keywords). Maak eerst die tabel en het zou goed moeten werken.
Als dit niet het geval is, verwijdert u de instructie voor de refererende sleutel en voegt u deze toe nadat de tabel is gemaakt – u krijgt een meer betekenisvolle foutmelding over de specifieke beperkingsfout.
Antwoord 8, autoriteit 6%
Er zijn nogal wat dingen die errno 150 kunnen veroorzaken, dus voor mensen die in dit onderwerp zoeken, is dit een bijna volledige lijst (bron Oorzaken van Errno 150):
Voor errno 150 of errno 121, typt u gewoon SHOW ENGINE INNODB STATUS in, er is een sectie met de naam “LAATSTE BUITENLANDSE SLEUTELFOUT”. Daaronder krijgt u een zeer nuttige foutmelding, die u meestal meteen vertelt wat er aan de hand is. Je hebt SUPER-rechten nodig om het uit te voeren, dus als je dat niet hebt, moet je de volgende scenario’s uitproberen.
1) Gegevenstypen komen niet overeen: de typen kolommen moeten hetzelfde zijn
2) Bovenliggende kolommen niet geïndexeerd (of in verkeerde volgorde geïndexeerd)
3) Kolomsorteringen komen niet overeen
4) SET NULL gebruiken op een NIET NULL-kolom
5) Tabelsorteringen komen niet overeen: zelfs als de kolomsorteringen overeenkomen, kan dit op sommige MySQL-versies een probleem zijn.
6) Bovenliggende kolom bestaat niet echt in bovenliggende tabel. Controleer de spelling (en eventueel een spatie aan het begin of einde van de kolom)
7) Een van de indexen op een van de kolommen is onvolledig, of de kolom is te lang voor een volledige index. Merk op dat MySQL (tenzij je het aanpast) een maximale sleutellengte voor één kolom heeft van 767 bytes (dit komt overeen met een varchar(255) UTF-kolom)
Als u een errno 121 krijgt, zijn hier een aantal oorzaken:
1) De naam van de beperking die je hebt gekozen, is al in gebruik
2) Op sommige systemen als er een verschil in hoofdletters is in uw verklaring en tabelnamen. Dit kan je bijten als je van de ene server naar de andere gaat met verschillende regels voor het behandelen van dossiers.
Antwoord 9, autoriteit 5%
Soms is MySQL gewoon super dom – ik kan de reden van buitenlandse sleutels begrijpen… maar in mijn geval heb ik zojuist de hele database verwijderd en krijg ik nog steeds de foutmelding… waarom? ik bedoel, er is geen database meer… en de sql-gebruiker die ik gebruik heeft geen toegang tot andere db’s op de server… ik bedoel, de server is “leeg” voor de huidige gebruiker en ik krijg nog steeds deze fout? Sorry, maar ik denk dat MySQL tegen me liegt… maar ik kan ermee omgaan 🙂 Voeg gewoon deze twee regels SQL toe rond je verdomde statement:
SET FOREIGN_KEY_CHECKS = 0;
# some code that gives you errno: 150
SET FOREIGN_KEY_CHECKS = 1;
Nu zou de sql moeten worden uitgevoerd… Als je echt een probleem met een refererende sleutel hebt, zou het aan je verschijnen bij de regel waar je de controles opnieuw wilt inschakelen – dit zal dan mislukken.. maar mijn server is gewoon stil 🙂
Antwoord 10, autoriteit 3%
Ik had hetzelfde probleem. Het was gerelateerd aan de tabelkolom Collatieen Tekenset.
Zorg ervoor dat Tekenseten Collatiehetzelfde moeten zijn voor beide kolommen in twee tabellen. Als je daar een externe sleutel op wilt zetten.
Voorbeeld- Als u een externe sleutel in de userID-kolom van de userImage-tabel plaatst die verwijst naar de userID-kolom van de gebruikerstabel. Dan moet de sortering hetzelfde zijn, namelijk utf8_general_cien de tekenset utf8voor beide kolommen van tafels. Over het algemeen neemt mysql, wanneer u een tabel aanmaakt, deze twee configuraties van de serverinstellingen.
Antwoord 11, autoriteit 2%
Na het doornemen van de bovenstaande antwoorden en wat experimenteren, is dit een effectieve manier om Foreign Key-fouten in MySQL (1005 – error 150) op te lossen.
Om de externe sleutel correct te maken, vraagt MySQL alleen om:
- Alle sleutels waarnaar wordt verwezen MOETEN een PRIMAIRE of UNIEKE index hebben.
- Opnieuw verwijzende kolom MOET hetzelfde gegevenstype hebben als de kolom waarnaar wordt verwezen.
Voldoe aan deze vereisten en alles komt goed.
Antwoord 12, autoriteit 2%
Ik heb deze fout ervaren toen ik de Windows-toepassing naar Linux heb geporteerd. In Windows zijn databasetabelnamen hoofdletterongevoelig en in Linux zijn ze hoofdlettergevoelig, waarschijnlijk vanwege het verschil in bestandssysteem. Dus in Windows is tabel Table1hetzelfde als Table1, en in REFERENCESzowel Table1als Table1werkt. Op Linux, toen de applicatie Table1gebruikte in plaats van Table1toen het een databasestructuur creëerde, zag ik fout #150; toen ik de juiste hoofdlettergebruik maakte in Table1referenties, begon het ook op Linux te werken. Dus als niets anders helpt, zorg er dan voor dat je in REFERENCESde juiste hoofdlettergebruik in de tabelnaam gebruikt als je Linux gebruikt.
Antwoord 13, autoriteit 2%
meestal is de mismatch tussen refererende sleutel & primaire sleutel zorgt ervoor dat de
fout:150.
De vreemde sleutelmoet hetzelfde datatypehebben als de primaire sleutel. Als de primaire sleutelniet-ondertekendis, moet de buitenlandse sleutelook niet-ondertekendzijn.
Antwoord 14, autoriteit 2%
Verander de engines van uw tabellen, alleen innoDB ondersteunt externe sleutels
Antwoord 15, autoriteit 2%
Als de PK-tabel in de ene CHARSETis gemaakt en je vervolgens de FK-tabel in een andere CHARSET maakt..dan krijg je misschien ook deze foutmelding…Ik kreeg ook deze fout, maar na het wijzigen van de charset naar PK charset en werd uitgevoerd zonder fouten
create table users
(
------------
-------------
)DEFAULT CHARSET=latin1;
create table Emp
(
---------
---------
---------
FOREIGN KEY (userid) REFERENCES users(id) on update cascade on delete cascade)ENGINE=InnoDB, DEFAULT CHARSET=latin1;
Antwoord 16, autoriteit 2%
Deze fout kan optreden als twee tabellen een referentie hebben, bijvoorbeeld een tabel is Student en een andere tabel is Education, en we willen dat de Education-tabel een refererende sleutelreferentie heeft van Student table. In dit geval moet het kolomgegevenstype voor beide tabellen hetzelfde zijn, anders wordt er een fout gegenereerd.
Antwoord 17, autoriteit 2%
In de meeste gevallen is het probleem te wijten aan het ENGINE-verschil. Als de ouder is gemaakt door InnoDB, dan worden de tabellen waarnaar wordt verwezen, gemaakt door MyISAM & omgekeerd
Antwoord 18, autoriteit 2%
In mijn geval. Ik had problemen met engine en charset omdat mijn Hosting-server instellingen veranderde en mijn nieuwe tabellen MyISAM waren, maar mijn oude tabellen zijn InnoDB. Ik ben alleen veranderd.
Antwoord 19
Zorg ervoor dat zowel uw primaire sleutelkolom als de kolom waarnaar wordt verwezen, dezelfde gegevenstypen en kenmerken hebben (niet-ondertekend, binair, niet-ondertekend zerofill, enz.).
Antwoord 20
Een echte edge-case is waar je een MySQL-tool hebt gebruikt (Sequel Pro in mijn geval) om een database te hernoemen. Vervolgens een database gemaakt met dezelfde naam.
Hierdoor werden beperkingen voor refererende sleutels behouden voor dezelfde databasenaam, dus de hernoemde database (bijv. my_db_renamed) had beperkingen voor externe sleutels in de nieuw aangemaakte database (my_db)
Ik weet niet zeker of dit een bug is in Sequel Pro, of dat een bepaalde use case dit gedrag vereist, maar het kostte me het meeste van de ochtend :/
Antwoord 21
Ik had dezelfde fout. In mijn geval was de reden voor de fout dat ik een ON DELETE SET NULL-instructie in de beperking had, terwijl het veld waarop ik de beperking in de definitie had gezet een NOT NULL-instructie had. Door NULL in het veld toe te staan, is het probleem opgelost.
Antwoord 22
Ik heb met dit soort problemen te maken gehad bij het maken van DB vanuit het tekstbestand.
mysql -uroot -padmin < E:\important\sampdb\createdb.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_absence.sql
Ik heb zojuist de bovenstaande regels geschreven in Create.baten voer het bat-bestand uit.
Mijn fout zit in de volgorde van uitvoering in mijn sql-bestanden. Ik heb geprobeerd een tabel te maken met een primaire sleutel en ook een externe sleutel. Terwijl het actief is, zoekt het naar de referentietabel, maar tabellen zijn er niet.
Dus het zal dat soort fouten retourneren.
Als u tabellen met een externe sleutel maakt, controleer dan de referentie
tafels waren aanwezig of niet. En controleer ook de naam van de referentie
tabellen en velden.
Antwoord 23
Ik had een soortgelijk probleem, maar de mijne was omdat ik een nieuw veld aan een bestaande tabel toevoegde die data had, en het nieuwe veld verwees naar een ander veld uit de bovenliggende tabel en had ook de definitie van NOT NULL en zonder enige DEFAULT WAARDEN. – Ik ontdekte dat de reden dat dingen niet werkten was omdat
- Mijn nieuwe veld moest de lege velden automatisch vullen met een waarde uit de bovenliggende tabel op elke record, voordat de beperking kon worden toegepast. Elke keer dat de beperking wordt toegepast, moet de integriteit van de tabelgegevens intact blijven. Het implementeren van de beperking (Foreign Key) maar er waren enkele databaserecords die niet de waarden uit de bovenliggende tabel hadden, zou betekenen dat de gegevens corrupt zijn, dus MySQL zou NOOIT UW BEPERKTE AFHAVEN
Het is belangrijk om te onthouden dat dit specifieke scenario onder normale omstandigheden zou worden vermeden als u uw database ruim van tevoren had gepland en beperkingen had geïmplementeerd voordat gegevens werden ingevoegd.
De gemakkelijkere aanpak om dit gedoe te vermijden is om
- Sla uw databasetabellengegevens op
- Trunk de tabelgegevens (en tabelartefacten, zoals indexen, enz.) af
- Pas de beperkingen toe
- Uw gegevens importeren
Ik hoop dat dit iemand helpt
Antwoord 24
Misschien ditzal helpen? De definitie van de primaire sleutelkolom moet exact hetzelfde zijn als de externe sleutelkolom.
Antwoord 25
Zorg ervoor dat alle tabellen externe sleutels kunnen ondersteunen – InnoDB-engine
Antwoord 26
De kolom van de PARENT-tabel waarnaar u verwijst vanuit de onderliggende tabel moet uniek zijn. Als dit niet het geval is, veroorzaakt u een fout nr. 150.
Antwoord 27
Ik had een soortgelijk probleem bij het dumpen van een Django mysql-database met een enkele tabel. Ik kon het probleem oplossen door de database naar een tekstbestand te dumpen, de betreffende tabel naar het einde van het bestand te verplaatsen met behulp van emacs en het gewijzigde sql-dumpbestand in de nieuwe instantie te importeren.
HTH Uwe
Antwoord 28
Ik heb het probleem verholpen door de variabele null
te laten accepteren
ALTER TABLE `ajout_norme`
CHANGE `type_norme_code` `type_norme_code` VARCHAR( 2 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL
Antwoord 29
Ik kreeg hetzelfde probleem bij het uitvoeren van een reeks MySQL-commando’s. De mijne treedt op tijdens het maken van een tabel bij het verwijzen naar een externe sleutel naar een andere tabel die nog niet is gemaakt. Het is de volgorde van het bestaan van een tabel voordat er wordt verwezen.
De oplossing: maak eerst de bovenliggende tabellen voordat u een onderliggende tabel maakt die een externe sleutel heeft.
Antwoord 30
Maak de tabel zonder externe sleutel en stel vervolgens de externe sleutel afzonderlijk in.