Toon posts:

[MySQL] Error 1005 Can't create table (errno: 150)

Pagina: 1
Acties:
  • 798 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
In het kort; ik heb een database ontwerp gemaakt en nu wil ik het gaan implementeren in MySQL. Bij het aanmaken van een nieuwe tabel krijg ik bovenstaande error (topic title).

De situatie:
Ik gebruik MySQL Server version: 3.23.49a-Max-log -->
http://www.mysql.com/Downloads/MySQL-Max-3.23/mysql-max-3.23.49a-pc-linux-gnu-i686.tar.gz

Als client gebruik ik MySQL Control Center 0.8.2 alpha -->
http://www.mysql.com/Downloads/MyCC/mycc-0.8.2-alpha-win32.zip

In een lege database voer ik de volgende SQL commando's uit:

CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id), FOREIGN KEY (parent_id) REFERENCES parent(id)) TYPE=INNODB;
INSERT INTO parent (id) VALUES(1);
INSERT INTO parent (id) VALUES(2);
INSERT INTO child (id,parent_id) VALUES(1,2);
INSERT INTO child (id,parent_id) VALUES(2,9); // KAN NIET > parent(9) bestaat NIET!
DELETE FROM parent WHERE id=2; // KAN NIET ? > child(1) verwijst HIERNA!

De laatste twee command's worden niet uitgevoerd omdat InnoDB er voor zorgt dat je geen records kan verwijderen die een referentie hebben in een andere tabel. Dit werkt perfect, dit moet ik hebben.

Nu probeer ik hetzelfde in maar dan net even anders:

CREATE TABLE Werknemers (
werknemerID mediumint(16) unsigned NOT NULL auto_increment,
werknemerNaam varchar(32) NOT NULL,
PRIMARY KEY (werknemerID)
) TYPE=InnoDB;

CREATE TABLE Gebruikers (
gebruikerID mediumint(16) unsigned NOT NULL auto_increment,
gebruikerNaam varchar(32) NOT NULL,
wachtwoord varchar(32) NOT NULL,
refWerknemerID mediumint(16) unsigned NOT NULL,
PRIMARY KEY (gebruikerID),
FOREIGN KEY (refWerknemerID) REFERENCES Werknemers(werknemerID)
) TYPE=InnoDB;

Het tweede commando om de tabel Gebruikers aan te maken geeft een error:

[myDataBase] ERROR 1005: Can't create table './ISvMMdb/Gebruikers.frm' (errno: 150)

Ik heb al heel wat andere SQL statements geprobeert, maar zonder resultaat. WAT ZIE IK OVER HET HOOFD?

Via de (GoT) search kon ik niet echt iets vinden. Via Google heb ik de volgende pagina gevonden:
http://dbforums.com/archive/114/2001/12/4/241880

Verder staat er in de InnoDB manual ( http://www.innodb.com/ibman.html ):

1005 ER_CANT_CREATE_TABLE Cannot create table. If the error message string refers to errno 150, then table creation fails because a foreign key constraint is not correctly formed.

Verder staan er nog wat andere zaken, maar daar krijg ik het probleem niet mee opgelost. In de MySQL manual kan ik ook geen antwoord vinden.

Ik werk nog maar zeer recent met MySQL. InnoDB heb ik vandaag voor het eerst gebruikt. Misschien dat ik morgen na nog een keer half internet door te spitten er wel uit kom. Maar dat het ene wel werkt en het andere niet, zoals hier boven, vind ik toch wel zeer opmerkelijk!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Op donderdag 11 april 2002 17:45 schreef DrDre3 het volgende:
[myDataBase] ERROR 1005: Can't create table './ISvMMdb/Gebruikers.frm' (errno: 150)
.frm is toch een MyIsam tabel?

  • Grum
  • Registratie: Juni 2001
  • Niet online
Nee .. InnoDB maakt die files ook aan (wellis waar in een andere subdir maar ok)

Misschien is dit gewoon domweg een rechten probleem :)

  • Goodielover
  • Registratie: November 2001
  • Laatst online: 18-08 11:34

Goodielover

Only The Best is Good Enough.

Ik weet niet off InnoDB het kan, maar je zou ook eerst de tabel kunnen creeren zonder constraint en dan later de constraint met een alter table toevoegen.

Nog een andere suggestie. Moet er een commit tussen de statements. Het zou compleet tegen mijn beeld ingaan. Aangezien normaal gesproken elk DD-statement een auto-commit uitvoert en je bovendien binnen dezelfde sessie het uitvoert.

Nog een mogelijkheid, definieer de kolom eens als nullable. en dan later weer als NOT NULL

Verwijderd

Topicstarter
Allemaal bedankt voor jullie reactie!

Schrijf en leesrechten in Linux: Een drama voor mensen zoals mij! Ik sluit het uit dat het daar aan ligt omdat het voorbeeld met parent-child vlekkeloos gaat (ook in verschillende databases).

De ALTER TABLE oplossing: Op http://www.innodb.com/ibman.html#InnoDB_foreign_keys
staat wel zoiets dat het met ALTER TABLE moet kunnen MAAR wel vanaf versie 3.23.50! Heb ik nou net weer de versie ervoor. Geen probleem zou je zeggen; downloaden via:
http://www.innodb.com/download.html
Wat blijkt: Het is een preRelease met alle gevolgen vandien. Er moeten bestaande bestanden overschreven worden. Lekker simpel, maar ik kan ze toch echt niet vinden vreemd genoeg (via 'Search' binnen Linux). Ook niet ha%innobase.* vanaf file:/.

Nogmaals; ik wil niet teveel op een zij-spoor zitten. Ik wil een database met relaties en met behulp van InnoDB kan dat. Zelfs nu al binnen de databases die ik heb. Daarom denk ik dat bovenstaande niet de goede mannier is om tot de oplossing te komen.
Op donderdag 11 april 2002 21:03 schreef Goodielover het volgende:
Ik weet niet off InnoDB het kan, maar je zou ook eerst de tabel kunnen creeren zonder constraint en dan later de constraint met een alter table toevoegen.

Nog een andere suggestie. Moet er een commit tussen de statements. Het zou compleet tegen mijn beeld ingaan. Aangezien normaal gesproken elk DD-statement een auto-commit uitvoert en je bovendien binnen dezelfde sessie het uitvoert.

Nog een mogelijkheid, definieer de kolom eens als nullable. en dan later weer als NOT NULL
1: Zie hierboven.
2: Statements eindigen bij mij met een ';'. Ik voer alles per statement uit (als je dat bedoelde).
3: unsigned en/of NOT NULL ... of helemaal zonder; het maakt niet uit.

Heb net nog even het parent-child voorbeeld getest op FK's: Als een trein! Heel de database leeggooien en weer de tabellen parent en child aanmaken; geen probleem. Volgens mij is het echt iets akkelig simpels (vrees ik).

Verwijderd

Topicstarter
Yeahoo! --> het werkt! :)

Het is inderdaad kinderachtig eenvoudig, in de zin van; zoek de twee verschillen.
De 'child' tabel moet in iedergeval de refererende kolom index-en. Dit doe ik zo i zo wel, maar dan meestal met de PK kolom. Die gedachte kronkel is me dan ook fitaal geweest gisteren.
Helemaal logisch is het trouwens niet, want het is volgens mij geen goede implementatie van de SQL-92 standaard. Vragen om problemen dus. Wat die MySQL jongens wel vaker doen onder het mom van snelheid. ;)

Ik zal nog even voor het volgende slachtoffer de goede goede SQL geven (een topic zonder 'goed einde' is ook maar een beetje jammerrr):

CREATE TABLE Werknemers (
werknemerID int(11) unsigned NOT NULL auto_increment,
werknemerNaam varchar(32) NOT NULL default '',
PRIMARY KEY (werknemerID),
UNIQUE KEY WerknemerID (werknemerID),
INDEX (werknemerID)
) TYPE=InnoDB;


CREATE TABLE Gebruikers (
gebruikerID int(11) unsigned NOT NULL auto_increment,
gebruikerNaam varchar(32) NOT NULL default '',
wachtwoord varchar(32) NOT NULL default '',
werknemerID int(11) unsigned NOT NULL,
PRIMARY KEY (gebruikerID),
UNIQUE KEY gebruikerID (gebruikerID),
INDEX (werknemerID), ##### DEZE REGEL DUS #####
FOREIGN KEY (werknemerID) REFERENCES Werknemers(werknemerID)
) TYPE=InnoDB;

Als er niemand meer wat toe te voegen heeft mag er wat mij betreft een slotje op.
Pagina: 1