mysql Yabancı anahtar kısıtı yanlış biçimlendirilmiş hata

İki tablo var, table1bir sütun ile üst tablodur IDve table2bir sütun ile IDFromTable1ben bir FK koymak (değil gerçek ismi) IDFromTable1için IDde table1hatası alıyorum Foreign key constraint is incorrectly formed error. table1Kayıt silinirse tablo 2 kaydını silmek istiyorum . Herhangi bir yardım için teşekkürler

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

Başka bilgi gerekip gerekmediğini bana bildirin. Mysql için yeniyim

HeidiSQL ile de aynı problemle karşılaştım. Aldığınız hata çok şifreli. Benim sorunum, yabancı anahtar sütun ve referans sütun aynı tür veya uzunlukta değildi oldu.

Yabancı anahtar sütunu oldu SMALLINT(5) UNSIGNEDve başvurulan sütun INT(10) UNSIGNED. Her ikisini de aynı tipte yaptığımda, yabancı anahtar yaratma mükemmel çalıştı.

Üst tablo MyISAMmotor kullanılarak oluşturulduğunda da aynı sorunu yaşadım . Aşağıdakilerle düzelttiğim aptalca bir hata:

ALTER TABLE parent_table ENGINE=InnoDB;

sütunların aynı (aynı türden) olduğundan emin olun ve referans sütunu değilse primary_key, olduğundan emin olun INDEXED.

Yabancı anahtarları tanımlamak için sözdizimi çok bağışlayıcıdır, ancak bunu yapan herkes için yabancı anahtarların "aynı türden" olması gerektiği gerçeği, yalnızca veri türü ve uzunluğu ve bit imzalaması için değil, harmanlama için de geçerlidir.

Harmanlamayı modelinizde karıştıracağınızdan (değil mi?), Ancak yaparsanız, birincil ve yabancı anahtar alanlarınızın phpmyadmin veya Heidi SQL'de veya kullandığınız her türde aynı harmanlama türünde olduğundan emin olun.

Umarım bu size dört saatlik deneme süresi kazandırır ve hata bana mal olur.

Aynı problemim vardı, ama çözdüm.

'Table1' sütunundaki 'ID' sütununun BENZERSİZ dizinine sahip olduğundan emin olun !

Ve elbette bu iki tablodaki 'ID' ve 'IDFromTable1' sütunlarının tipi, uzunluğu aynı olmalıdır. Ama bunu zaten biliyorsun.

Sadece tamamlamak için.

Bu hata, VARCHAR (..) ile yabancı bir anahtarınız varsa ve başvurulan tablonun karakter seti referans veren tablodan farklıysa da bu durum söz konusu olabilir.

örneğin, Latin1 Tablosundaki VARCHAR (50), UTF8 Tablosundaki VARCHAR (50) 'den farklıdır.

mysql hata metinleri o kadar yardımcı olmuyor, benim durumumda, sütun "boş değil" kısıtlaması vardı, bu nedenle "silme kümesinde boş" izin verilmedi

her şey yolundaysa, ->unsigned();sonuna ekleyin foregin key.

Eğer çalışmazsa, her iki alanın da veri tipini kontrol edin. aynı olmalılar.

Ben de aynı sorunu vardı, her iki sütun INT (11) NULL DEĞİLDİ ama yabancı anahtar oluşturmak mümkün değil. Başarıyla çalıştırmak için yabancı anahtar denetimlerini devre dışı bırakmak zorunda kaldım:

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

Umarım bu birine yardımcı olur.

Bu hatanın görüntülenmesi için bir olası neden daha. Hangi tablolar oluşturma sırası yanlıştı. Henüz oluşturulmamış bir tablodan bir anahtara başvurmaya çalışıyordum.

(Son Yeniden Gönderme) Alan adı ve veri türü aynı, ancak harmanlama aynı olmasa bile, bu soruna da neden olacaktır.

Örneğin

    TBL ADI | VERİ TÜRÜ | COLLATION        

    Etkinlik Kimliği | INT |         latin1_general_ci     ActivityID | INT |         utf8_general_ci

Olarak değiştirmeyi deneyin

    TBL ADI | VERİ TÜRÜ | COLLATION        

    Etkinlik Kimliği | INT |         latin1_general_ci     ActivityID | INT |         latin1_general_ci

....

Bu benim için çalıştı.

Masa motorunu kontrol edin, her iki masa da aynı motor olmalı, bu da bana çok yardımcı oldu.

Aynı sorunları yaşadım.

Sorun, referans sütununun birincil anahtar olmamasıdır.

Birincil anahtar yapın ve sorun çözüldü.

Diğer cevaplar oldukça yararlı olsa da, sadece deneyimimi paylaşmak istedim.

idZaten diğer tablolarda ( veri ile ) yabancı anahtar olarak başvurulmakta olan bir tablo sildi ve yeniden oluşturmak / bazı ek sütunlarla tablo almak çalıştı sorunla karşı karşıya .

(PhpMyAdmin'de oluşturulan) rekreasyon sorgusu aşağıdaki gibi görünüyordu:

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`);

Fark edebileceğiniz gibi, PRIMARY KEYdizin oluşturulduktan ( ve verilerin eklenmesinden sonra) soruna neden olan ) .

Çözüm

Çözüm, bunun için yabancı anahtar olarak başvurulan PRIMARY KEYtablo tanımı sorgusuna dizin eklemek ve idayrıca ALTER TABLEdizinlerin ayarlandığı kısımdan kaldırmaktı :

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;

Bunun için saatlerce kaybettim!

PK bir tabloda utf8diğer oldu utf8_unicode_ci!

Aşağıdakileri çalıştırmayı deneyin:

show create table Üst öğe

// ve her iki tablonun türünün myISAM veya innoDB gibi aynı olup olmadığını kontrol edin.
// Bu hata mesajıyla kontrol edilecek diğer hususlar: yabancı olarak kullanılan sütunlar 
anahtarlar dizine eklenmeli, aynı türde olmalıdır 
(yani biri smallint (5) ve diğeri smallint (6) tipindeyse, 
işe yaramaz) ve tamsayılarsa imzasız olmalıdırlar.

// veya karakter kümelerini kontrol et
"character_set_database" gibi değişkenleri göster;
"collation_database" gibi değişkenleri göster;

// düzenlendi: böyle bir şey deneyin
ALTER TABLE tablo2
CONSTRAINT EKLE fk_IdTable2
YABANCI ANAHTAR (Tablo1_Id)
REFERANSLAR Tablo1 (Tablo1_Id)
GÜNCELLEME KASKASINDA 
SİLİNDİR SİLİNDİRİNDE;

Aynı sorunu Symfony 2.8 ile de yaşadım.

İlk başta anlayamadım, çünkü yabancı anahtarların int uzunluğunda benzer bir sorun yoktu.

Sonunda proje klasöründe aşağıdakileri yapmak zorunda kaldım. (Bir sunucunun yeniden başlatılması yardımcı olmadı!)

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

teşekkürler S Doerin:

"Tamamlanması için. VARCHAR (..) ile yabancı bir anahtarınız varsa ve başvurulan tablonun karakter kümesi referans veren tablodan farklıysa, bu hata da olabilir. Örneğin, Latin1 Tablosundaki VARCHAR (50) UTF8 Tablosundaki VARCHAR'dan (50) farklı. "

tablonun karakter türünü değiştirerek, bu sorunu çözdü. yaratılış latin1 ve doğru utf8.

sonraki satırı ekleyin. VARSAYILAN KARAKTER SETİ = utf8;

İki tablo arasında bir yabancı anahtar eklemek için Alter tablo kullanarak sorunları vardı ve bana yardımcı olan şey, ben bir yabancı anahtar ilişkisi eklemek çalışıyorum her sütun dizine emin olmak oldu. Bunu PHP myAdmin'de yapmak için: Tabloya gidin ve yapı sekmesine tıklayın. Ekran görüntüsünde gösterildiği gibi istenen sütunu dizine eklemek için dizin seçeneğini tıklayın:

Her iki sütunu da indeksledikten sonra yabancı anahtarlarımla başvurmaya çalışıyordum, değiştirme tablosunu başarılı bir şekilde kullanabildim ve yabancı anahtar ilişkisini oluşturabildim. Sütunların aşağıdaki ekran görüntüsünde olduğu gibi dizine eklendiğini göreceksiniz:

zip_code'un her iki tabloda nasıl göründüğüne dikkat edin.

"Harmanlama" da dahil olmak üzere her ikisinin de tüm özelliklerinde aynı olup olmadığını kontrol etmeniz gerekir.

HeidiSQL kullanıyordum ve bu sorunu çözmek için başvurulan tabloda tüm sütunların başvuruda bulunduğu bir dizin oluşturmak zorunda kaldım .

Ben de şimdi aynı konuya girdim. Benim durumumda, tek yapmam gereken yabancı anahtarda referans verdiğim tablonun geçerli tablonun (kodun başlarında) öncesinde oluşturulmasını sağlamaktır. Dolayısıyla, bir değişkene (x * 5) başvuruyorsanız, sistem x'in ne olduğunu bilmelidir (x önceki kod satırlarında bildirilmelidir). Bu sorunumu çözdü, umarım başka birine yardım eder.

MariaDB 10.1 ile Laravel 5.1 geçiş Schema Builder ile de aynı sorunu yaşadım.

Sorunum yazmışsınız olmasıydı unignedyerine unsigned(s sütun ayarlarken harf eksik) yazmıştı.

Düzelttikten sonra yazım hatası düzeltildi.

Hatta mysql ve liquibase ile aynı konuya rastladım. Yani sorun budur: Başka bir tablonun sütununa başvurmak istediğiniz tablo, veri tipi durumunda veya veri tipinin boyutu açısından farklıdır.

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.

Uygun durumda tablonun adını belirttiğinizden emin olun (tablo adları veritabanınızda büyük / küçük harfe duyarlıysa). Benim durumumda değiştirmek zorunda kaldım

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

için

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

olarak customerdeğiştirildiğine dikkat edin CUSTOMER.

Veya veritabanınızı oluşturmak ve bunları FK kullanarak bağlamak için grafiksel bir arayüze sahip DBDesigner4'ü kullanabilirsiniz. Tablonuza sağ tıklayın ve kodu oluşturan 'Tablo SQL Oluşturma Kopyala'yı seçin.

Bu eski bir konu ama bir şey keşfettim. Bir MySQL çalışma tezgahı oluştururken, diğer tablonun ilişkilerini de alır. sadece ilgili sütunları bırakın. Otomatik olarak eklenen diğer sütunları temizleyin. Bu benim için çalışıyor.

Benim durumum, belirtilen sütunda bir yazım hatası vardı:

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")

Hata mesajı oldukça şifreli ve her şeyi denedim - sütun türlerini, harmanlamaları, motorları vb.

Yazım hatası not etmek biraz zaman aldı ve düzelttikten sonra hepsi iyi çalıştı:

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

Birincil anahtarı aşağıdaki gibi farklı veri türüne koyduğunuzda hata geldi bu sorunla karşı karşıya:

tablo 1:

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

Tablo 2:

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

ikinci tablonun kimliği için veri türü artımlı olmalıdır

Sorunu çözmek çok basit

Örneğin: Eğer isimleri ile iki tablo var kullanıcılar ve mesajların ve oluşturmak istediğiniz yabancı anahtar içinde mesajlar masa ve kullandığınız phpMyAdmin'i

1) 'de sonrası masaya eklemek yeni sütun ( isim | use_id: türü : gibi id içinde kullanıcı tablosu | Uzunluk : gibi id içinde kullanıcı tablosu | Varsayılan : NULL | Nitelikler : işaretsiz | index: INDEX)

2) Yapı sekmesinde ilişki görünümüne gidin ( Kısıtlama adı : phpmyAdmin | sütun adı tarafından otomatik olarak ayarlanır : select user_id | table : users | key : id, ...)

Basitçe çözüldü

javad mosavi iran / urmia