mysql Ograniczenie klucza obcego jest nieprawidłowo sformułowanym błędem

Mam dwie tabele, table1to tabela nadrzędna z kolumnąID i table2z kolumny IDFromTable1(nie rzeczywista nazwa), kiedy kładę FK na IDFromTable1celu IDw table1pojawia się błąd Foreign key constraint is incorrectly formed error. Chciałbym usunąć rekord tabeli 2, jeśli table1zostanie usunięty. Dzięki za wszelką pomoc

ALTER TABLE `table2`  
   ADD CONSTRAINT `FK1` 
      FOREIGN KEY (`IDFromTable1`) REFERENCES `table1` (`ID`) 
      ON UPDATE CASCADE 
      ON DELETE CASCADE;

Daj mi znać, jeśli potrzebujesz innych informacji. Jestem nowy w mysql

Napotkałem ten sam problem z HeidiSQL. Otrzymany błąd jest bardzo tajemniczy. Mój problem polegał na tym, że kolumna klucza obcego i kolumna odwołująca się nie były tego samego typu lub długości.

Kolumna klucza obcego to, SMALLINT(5) UNSIGNEDa kolumna, do której się odwołuje - to INT(10) UNSIGNED. Kiedy utworzyłem dla obu dokładnie ten sam typ, tworzenie klucza obcego działało idealnie.

Miałem ten sam problem podczas tworzenia tabeli nadrzędnej za pomocą MyISAMsilnika. To głupi błąd, który naprawiłem:

ALTER TABLE parent_table ENGINE=InnoDB;

upewnij się, że kolumny są identyczne (tego samego typu), a jeśli kolumna odniesienia nie jest primary_key, upewnij się, że tak INDEXED.

Składnia definiowania kluczy obcych jest bardzo wyrozumiała, ale dla każdego, kto się o to potyka, fakt, że klucze obce muszą być „tego samego typu” dotyczy nawet sortowania, a nie tylko typu i długości danych oraz podpisywania bitów.

Nie żebyś mieszał sortowanie w swoim modelu (prawda?), Ale jeśli to zrobisz, upewnij się, że pola klucza podstawowego i obcego mają ten sam typ sortowania w phpmyadmin lub Heidi SQL lub czymkolwiek innym.

Mam nadzieję, że zaoszczędzi to czterech godzin prób i błędów, które mnie to kosztowało.

Miałem ten sam problem, ale rozwiązałem go.

Tylko upewnij się, że kolumna „ID” w „tabeli1” ma UNIKATOWY indeks!

Oczywiście typ i długość kolumn „ID” i „IDFromTable1” w tych dwóch tabelach muszą być takie same. Ale już o tym wiesz.

Tylko do ukończenia.

Ten błąd może również wystąpić, jeśli masz klucz obcy z VARCHAR (..) i zestaw znaków w tabeli, do której się odwołuje, różni się od tabeli, do której się odwołuje.

np. VARCHAR (50) w tabeli Latin1 różni się od VARCHAR (50) w tabeli UTF8.

teksty błędów mysql nie pomagają tak bardzo, w moim przypadku kolumna miała ograniczenie „not null”, więc ustawienie „on delete set null” nie było dozwolone

jeśli wszystko jest w porządku, po prostu dodaj ->unsigned();na końcuforegin key .

jeśli to nie zadziała, sprawdź typ danych obu pól. muszą być takie same.

Miałem ten sam problem, obie kolumny miały wartość INT (11) NOT NULL, ale nie mogę utworzyć klucza obcego. Musiałem wyłączyć sprawdzanie kluczy obcych, aby go pomyślnie uruchomić:

SET FOREIGN_KEY_CHECKS=OFF;
ALTER TABLE ... ADD CONSTRAINT ...
SET FOREIGN_KEY_CHECKS=ON;

Mam nadzieję, że to komuś pomoże.

Jeszcze jedna prawdopodobna przyczyna wyświetlenia tego błędu. Kolejność, w jakiej tworzyłem tabele, była nieprawidłowa. Próbowałem odwołać się do klucza z tabeli, która nie została jeszcze utworzona.

(Ostatnio ponownie wysłane) Nawet jeśli nazwa pola i typ danych są takie same, ale sortowanie nie jest takie samo, spowoduje to również ten problem.

Na przykład

    NAZWA TBL | TYP DANYCH | PORÓWNANIE        

    ActivityID | INT |         latin1_general_ci     ActivityID | INT |         utf8_general_ci

Spróbuj zmienić to na

    NAZWA TBL | TYP DANYCH | PORÓWNANIE        

    ActivityID | INT |         latin1_general_ci     ActivityID | INT |         latin1_general_ci

....

To zadziałało dla mnie.

Sprawdź silnik tabel, oba tabele muszą być tym samym silnikiem, który tak bardzo mi pomógł.

Miałem te same problemy.

Problem polega na tym, że kolumna odniesienia nie jest kluczem podstawowym.

Niech to będzie klucz podstawowy, a problem zostanie rozwiązany.

Chociaż inne odpowiedzi są dość pomocne, chciałem również podzielić się moim doświadczeniem.

Napotkałem problem, gdy usunąłem tabelę, do której idodwoływałem się już jako klucz obcy w innych tabelach ( z danymi ) i próbowałem odtworzyć / zaimportować tabelę z kilkoma dodatkowymi kolumnami.

Zapytanie o odtworzenie (wygenerowane w phpMyAdmin) wyglądało następująco:

CREATE TABLE `the_table` (
  `id` int(11) NOT NULL,            /* No PRIMARY KEY index */  
  `name` varchar(255) NOT NULL,
  `name_fa` varchar(255) NOT NULL,
  `name_pa` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

... /* SOME DATA DUMP OPERATION */

ALTER TABLE `the_table`
  ADD PRIMARY KEY (`id`), /* PRIMARY KEY INDEX */
  ADD UNIQUE KEY `uk_acu_donor_name` (`name`);

Jak możesz zauważyć, PRIMARY KEYindeks został ustawiony po utworzeniu ( i wstawieniu danych ), które powodowało problem.

Rozwiązanie

Rozwiązaniem było dodanie PRIMARY KEYindeksu w zapytaniu definiującym tabelę dla tego, do idktórego odwoływano się jako klucz obcy, jednocześnie usuwając go z ALTER TABLEczęści, w której ustawiane były indeksy:

CREATE TABLE `the_table` (
  `id` int(11) NOT NULL PRIMARY KEY,            /* <<== PRIMARY KEY INDEX ON CREATION */  
  `name` varchar(255) NOT NULL,
  `name_fa` varchar(255) NOT NULL,
  `name_pa` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Straciłem przez to wiele godzin!

PK w jednym stole był utf8w drugim utf8_unicode_ci!

Spróbuj wykonać następujące czynności:

pokaż stwórz tabelę Parent

// i sprawdź, czy typy dla obu tabel są takie same, np. myISAM lub innoDB itp
// Inne aspekty do sprawdzenia w tym komunikacie o błędzie: kolumny używane jako obce 
klucze muszą być indeksowane, muszą być tego samego typu 
(jeśli np. jeden jest typu smallint (5), a drugi typu smallint (6), 
to nie zadziała), a jeśli są liczbami całkowitymi, powinny być bez znaku.

// lub sprawdź zestawy znaków
pokaż zmienne takie jak „character_set_database”;
pokaż zmienne, takie jak "collation_database";

// edytowano: spróbuj czegoś takiego
ALTER TABLE tabela 2
DODAJ OGRANICZENIE fk_IdTable2
KLUCZ OBCY (Tabela1_Id)
ODNIESIENIA Tabela1 (Tabela1_Id)
W AKTUALIZACJI KASKADY 
NA DELETE CASCADE;

Miałem ten sam problem z Symfony 2.8.

Nie dostałem tego na początku, ponieważ nie było podobnych problemów z int długością kluczy obcych itp.

Wreszcie musiałem wykonać następujące czynności w folderze projektu. (Restart serwera nie pomógł!)

app/console doctrine:cache:clear-metadata app/console doctrine:cache:clear-query app/console doctrine:cache:clear-result

dzięki S Doerin:

„Tylko do uzupełnienia. Ten błąd może również wystąpić, jeśli masz klucz obcy z VARCHAR (..), a zestaw znaków w tabeli, do której się odwołuje, jest inny niż w tabeli, do której się odwołuje. Np. VARCHAR (50) w tabeli Latin1 to inny niż VARCHAR (50) w tabeli UTF8. "

Rozwiązałem ten problem, zmieniając rodzaj znaków w tabeli. kreacja ma latin1, a poprawna to utf8.

dodaj następną linię. DOMYŚLNY ZESTAW ZNAKÓW = utf8;

Miałem problemy z używaniem Alter table do dodania klucza obcego między dwiema tabelami, a pomogło mi upewnienie się, że każda kolumna, do której próbowałem dodać relację klucza obcego, została zindeksowana. Aby to zrobić w PHP myAdmin: Przejdź do tabeli i kliknij kartę struktury. Kliknij opcję indeksu, aby zindeksować żądaną kolumnę, jak pokazano na zrzucie ekranu:

Po zaindeksowaniu obu kolumn, do których próbowałem odwoływać się za pomocą moich kluczy obcych, udało mi się z powodzeniem użyć tabeli alter i utworzyć relację klucza obcego. Zobaczysz, że kolumny są indeksowane jak na poniższym zrzucie ekranu:

zwróć uwagę, jak kod_zip pojawia się w obu tabelach.

Musisz sprawdzić, czy oba są takie same we wszystkich swoich właściwościach, w tym w „Sortowaniu”

Używałem heidisql i rozwiązać ten problem miałem aby utworzyć indeks w tabeli odwołuje się wszystkie kolumny są odwoływać.

Właśnie teraz napotkałem ten sam problem. W moim przypadku wszystko, co musiałem zrobić, to upewnić się, że tabela, do której się odwołuję w kluczu obcym, musi zostać utworzona przed bieżącą tabelą (wcześniej w kodzie). Więc jeśli odwołujesz się do zmiennej (x * 5), system powinien wiedzieć, czym jest x (x musi być zadeklarowane we wcześniejszych wierszach kodu). To rozwiązało mój problem, mam nadzieję, że pomoże to komuś innemu.

Miałem ten sam problem z migracją Laravel 5.1 Schema Builder z MariaDB 10.1.

Problem polegał na tym, że unignedzamiast unsigned(s brakowało litery) wpisałem podczas ustawiania kolumny.

Po naprawieniu błędu literówki został dla mnie naprawiony.

Nawet ja napotkałem ten sam problem z mysql i liquibase. A więc na tym polega problem: Tabela, z której chcesz odwołać się do kolumny innej tabeli, różni się albo w przypadku typu danych, albo pod względem rozmiaru typu danych.

Error appears in below scenario:
Scenario 1:
Table A has column id, type=bigint
Table B column referenced_id type varchar(this column gets the value from the id column of Table A.)
Liquibase changeset for table B:

    <changeset id="XXXXXXXXXXX-1" author="xyz">
            <column name="referenced_id" **type="varchar"**>
        </column>
            </changeset>
    <changeSet id="XXXXXXXXXXX-2" author="xyz">
                <addForeignKeyConstraint constraintName="FK_table_A"
                    referencedTableName="A" **baseColumnNames="referenced_id**"
                    referencedColumnNames="id" baseTableName="B" />
    </changeSet>

Table A changeSet:

    <changeSet id="YYYYYYYYYY" author="xyz">
     <column **name="id"** **type="bigint"** autoIncrement="${autoIncrement}">
                    <constraints primaryKey="true" nullable="false"/>
                </column>
    </changeSet>

Solution: 
correct the type of table B to bigint because the referenced table has type bigint.

Scenrario 2:
The type might be correct but the size might not.
e.g. :
Table B : referenced column type="varchar 50"
Table A : base column type ="varchar 255"

Solution change the size of referenced column to that of base table's column size.

Sprawdź, czy nazwa tabeli jest podana w odpowiedniej wielkości (jeśli nazwy tabel w bazie danych uwzględniają wielkość liter). W moim przypadku musiałem się zmienić

 CONSTRAINT `FK_PURCHASE_customer_id` FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) ON UPDATE CASCADE ON DELETE CASCADE

do

 CONSTRAINT `FK_PURCHASE_customer_id` FOREIGN KEY (`customer_id`) REFERENCES `CUSTOMER` (`id`) ON UPDATE CASCADE ON DELETE CASCADE

zwróć uwagę na customerzmianę na CUSTOMER.

Lub możesz użyć DBDesigner4, który ma interfejs graficzny do tworzenia bazy danych i łączenia ich za pomocą FK. Kliknij prawym przyciskiem myszy swoją tabelę i wybierz „Kopiuj tworzenie SQL tabeli”, co spowoduje utworzenie kodu.

To stary temat, ale coś odkryłem. Podczas budowania środowiska roboczego MySQL pobiera również relacje z drugiej tabeli. po prostu zostaw filary, do których się odnosisz. Wyczyść inne automatycznie dodane kolumny. To działa dla mnie.

Mój przypadek był taki, że miałem literówkę we wspomnianej kolumnie:

MariaDB [blog]> alter table t_user add FOREIGN KEY ( country_code ) REFERENCES t_country ( coutry_code );
ERROR 1005 (HY000): Can't create table `blog`.`t_user` (errno: 150 "Foreign key constraint is incorrectly formed")

Komunikat o błędzie jest dość tajemniczy i próbowałem wszystkiego - weryfikowania typów kolumn, sortowania, silników itp.

Zajęło mi trochę czasu, zanim zanotowałem literówkę, a po naprawieniu wszystko działało dobrze:

MariaDB [blog]> alter table t_user add FOREIGN KEY ( country_code ) REFERENCES t_country ( country_code );
Query OK, 2 rows affected (0.039 sec)              
Records: 2  Duplicates: 0  Warnings: 0

W obliczu tego problemu pojawił się błąd, gdy umieściłeś klucz podstawowy w innym typie danych, takim jak:

Tabela 1:

 Schema::create('products', function (Blueprint $table) {
            $table->increments('id');
            $table->string('product_name');
        });

Tabela 2:

Schema::create('brands', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('brand_name');
        });

typ danych dla id drugiej tabeli musi być przyrostem

Problem jest bardzo prosty do rozwiązania

np: masz dwie tabele z nazwami użytkowników i postami i chcesz utworzyć klucz obcy w tabeli postów i używasz phpMyAdmina

1) w tabeli postów dodaj nową kolumnę ( name : use_id | type : jak id w tabeli użytkownika | Length : jak id w tabeli użytkownika | Domyślnie : NULL | Atrybuty : unsigned | index: INDEX)

2) na karcie Struktura przejdź do widoku relacji ( Nazwa ograniczenia : automatycznie ustawiana przez phpmyAdmin | nazwa kolumny : wybierz identyfikator_użytkownika | tabela : użytkownicy | klucz : id, ...)

Po prostu został rozwiązany

javad mosavi iran / urmia