verifique - mysql Restrição de chave estrangeira é erro formado incorretamente




o que é chave estrangeira mysql (17)

(Último Reenvio) Mesmo que o nome do campo e o tipo de dados sejam os mesmos, mas o agrupamento não seja o mesmo, isso também resultará nesse problema.

Por exemplo

NOME TBL | TIPO DE DADOS | COLLAÇÃO

ActivityID | INT | latin1_general_ci ActivityID | INT | utf8_general_ci

Tente mudá-lo para

NOME TBL | TIPO DE DADOS | COLLAÇÃO

ActivityID | INT | latin1_general_ci ActivityID | INT | latin1_general_ci

....

Isso funcionou para mim.

Eu tenho duas tabelas, table1 é a tabela pai com um ID coluna e table2 com uma coluna IDFromTable1 (não o nome real) quando eu coloco um FK em IDFromTable1 para ID na table1 recebo o erro Foreign key constraint is incorrectly formed error . Gostaria de excluir o registro da tabela 2 se o registro table1 for excluído. Obrigado por qualquer ajuda

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

Deixe-me saber se alguma outra informação é necessária. Eu sou novo no mysql


A sintaxe para definir chaves estrangeiras é muito tolerante, mas para qualquer outra pessoa que acesse isso, o fato de chaves estrangeiras serem "do mesmo tipo" se aplica mesmo ao agrupamento, não apenas ao tipo e comprimento de dados e assinatura de bits.

Não que você misturasse collation em seu modelo (sim?), Mas se fizer isso, certifique-se de que seus campos de chave primária e estrangeira sejam do mesmo tipo de agrupamento em phpmyadmin ou Heidi SQL ou o que você usa.

Espero que isso economize as quatro horas de tentativa e erro que me custou.


Certifique-se de colunas são idênticas (do mesmo tipo) e se a coluna de referência não é primary_key , verifique se ele é INDEXED .


Embora as outras respostas sejam bastante úteis, só queria compartilhar minha experiência também.

Enfrentei o problema quando apaguei uma tabela cujo id já estava sendo referenciado como chave estrangeira em outras tabelas ( com dados ) e tentei recriar / importar a tabela com algumas colunas adicionais.

A consulta para recreação (gerada no phpMyAdmin) se pareceu com o seguinte:

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

Como você pode perceber, o índice PRIMARY KEY foi definido após a criação ( e inserção de dados ) que estava causando o problema.

Solução

A solução foi adicionar o índice PRIMARY KEY na consulta de definição de tabela para o id que estava sendo referenciado como chave estrangeira, e também removê-lo da parte ALTER TABLE que os índices estavam sendo definidos:

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;

Eu estava usando o HeidiSQL e para resolver esse problema eu tive que criar um índice na tabela referenciada com todas as colunas sendo referenciadas.


Eu perdi por horas para isso!

PK em uma tabela foi utf8 em outro foi utf8_unicode_ci !


Eu tive o mesmo problema com o Schema Builder de migração do Laravel 5.1 com o MariaDB 10.1.

A questão era que eu tinha digitado sem unigned vez de unsigned (a letra s estava faltando) enquanto unigned a coluna.

Depois de corrigir o erro de digitação foi corrigido para mim.


Eu tive o mesmo problema com o Symfony 2.8.

Eu não entendi em primeiro lugar, porque não houve problemas semelhantes com int tamanho de chaves estrangeiras etc.

Finalmente eu tive que fazer o seguinte na pasta do projeto. (A reinicialização do servidor não ajudou!)

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


Eu tive o mesmo problema, ambas as colunas foram INT (11) NOT NULL, mas eu não seria capaz de criar a chave estrangeira. Eu tive que desativar as verificações de chaves estrangeiras para executá-lo com sucesso:

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

Espero que isso ajude alguém.


Eu tive o mesmo problema, mas resolvi.

Apenas certifique-se de que a coluna 'ID' em 'table1' tenha um índice UNIQUE !

E, claro, o tipo, o comprimento das colunas "ID" e "IDFromTable1" nessas duas tabelas deve ser o mesmo. Mas você já sabe disso.


Mais uma causa provável para a exibição desse erro. A ordem em que eu estava criando tabelas estava errada. Eu estava tentando fazer referência a uma chave de uma tabela que ainda não foi criada.


Mesmo eu corri para o mesmo problema com o mysql e liquibase. Portanto, este é o problema: A tabela da qual você deseja referenciar uma coluna de outra tabela é diferente, seja no caso de tipo de dados ou em termos de tamanho do tipo de dados.

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.

Tente executar o seguinte:

show create table Parent

//and check if type for both tables are the same, like myISAM or innoDB, etc
//Other aspects to check with this error message: the columns used as foreign 
keys must be indexed, they must be of the same type 
(if i.e one is of type smallint(5) and the other of type smallint(6), 
it won't work), and, if they are integers, they should be unsigned.

//or check for charsets
show variables like "character_set_database";
show variables like "collation_database";

//edited: try something like this
ALTER TABLE table2
ADD CONSTRAINT fk_IdTable2
FOREIGN KEY (Table1_Id)
REFERENCES Table1(Table1_Id)
ON UPDATE CASCADE 
ON DELETE CASCADE;

Verifique o mecanismo de tabelas, ambas as tabelas tem que ser o mesmo motor, que me ajudou muito.


Você precisa verificar se ambos são iguais em todas as suas propriedades, inclusive em "Agrupamento"


obrigado S Doerin:

"Apenas para conclusão. Esse erro pode ser o caso se você tiver uma chave estrangeira com VARCHAR (..) e o conjunto de caracteres da tabela referenciada for diferente da tabela que faz referência a ela. Por exemplo, VARCHAR (50) em uma tabela Latin1 é diferente do VARCHAR (50) em uma Tabela UTF8. "

Eu resolvi esse problema, alterando o tipo de caracteres da tabela. a criação tem latin1 e o correto é utf8.

adicione a próxima linha. DEFAULT CHARACTER SET = utf8;


textos de erro do mysql não ajuda muito, no meu caso, a coluna tinha restrição "não nula", então o "on delete set null" não era permitido





heidisql