Olá pessoal,
Tenho dois campos que não são obrigatórios no cadastro e ambos são chaves estrangeiras. Quando tento inserir os dados aparece a mensagem:
Erro ao incluir na base de dados: Cannot add or update a child row: a foreign key constraint fails (`mdierpco_protocolo`.`b002_clientes`, CONSTRAINT `b002_clientes_fk3` FOREIGN KEY (`Setor_ID`) REFERENCES `a006_setores` (`Setor_ID`))
Como faço para que estes campos recebam valores nulos? Eles já estão ocultos do formulário.
Grato,
Ilano
A partir do momento que no banco tais campos são chaves estrangeiras esse devem ter conteúdo no momento da gravação, não da para fugir disso.
Então, mesmo eu definindo lá no banco de dados que esses campos possam ser NULOS o scriptcase não trata isso? Isso quer dizer que eu tenho que tirar lá do banco os vínculos entre as tabelas?
se você realizar um insert direto no banco da tabela em questão sem alimentar essas colunas o banco vai realizar o insert sem erros?
Haroldo,
Fazendo um insert no banco e passando NULL para esses campos ele aceita tranquilamente. Mas como no sistema estou usando Formulários, no insert do scriptcase ele passa 0 (zero). Não tem como burlar isso? Sei que eu poderia criar um controle e fazer isso manualmente, mas no formulário, não tem como contornar esse problema?
onBeforeInsert:
{campo}=NULL;
Haroldo,
Deu certo! Fiz o seguinte, além de sua sugestão, lá em Editar Campos, coloquei como padrão na coluna Valor DB (Insert) defini como NULO. Agora está salvando os registros corretamente.
Muito obrigado Haroldo.
Somente para eu entender.
Chave estrangeira tem que ser chave primária. Certo?
Se colocar valor null não compromete a integridade referencial?
Pergunto porque já é uma discussão velha na web sobre valores null em chave estrangeira.
Alexandre,
Isso depende de cada situação. Uma chave estrangeira não necessariamente deve ser NOT NULL. Existem casos em que você pode considerá-la NULL no banco de dados mas, como eu disse, depende da necessidade, depende de como esse banco fora concebido. Eu trabalho com Delphi e Visual Studio (usando VB) e realmente existem casos e casos. Por exemplo, se você tiver uma tabela para de PESSOAS ora, pessoas são físicas e jurídicas, um vendedor é uma pessoa, um cliente é uma pessoa, um fornecedor é uma pessoa, o aluno é uma pessoa e, dependendo de como aquela tabela for concebida cada pessoa tem informações peculiares, sendo assim, se faz necessário que algumas chaves estrangeiras sejam NULL, já outras não. Só reforçando o que disse desde o início, isso depende de como uma tabela for concebida. Mas concordo que, o ideal, seria mesmo NOT NULL.
Valeu!
Me desculpe mas devo discordar.
Se é forein key não deve ser nulo. Para isso que ele serve (não deixar registros órfãos).
No teu caso citado a baixo uma terceira tabela deve ser criada de ligação entre clientes e setores, uma tabela de junção, com o id do cliente e com o id do setor. Se a aplicação como funcionalidade tem a opção de não informar um setor para o cliente o registro nessa tabela de junção não é criado.
Clientes, Fornecedores, Vendedores, Alunos são entidades possuem dados em comum e particulares.
Não é uma boa prática usar uma mesma tabela para entidades diferentes.
Modelagem de banco de dados deve ser independente da linguagem.
Se definiu chave estrangeira em tabela ela seria obrigatória ser preenchida e não ficar NULA, porque isso?
Se ficar NULA toda vez que você for criar uma consulta e juntar as tabelas com JOIN nesta tabela que tem NULL,
você não vai poder usar simplesmente o padrão INNER JOIN, vai ter que sempre lembrar para o RESTO da vida, ali de usar o OUTER JOIN, se não
suas consultas vão vir faltando registros.
Sei que este post é antigo, no entanto, as respostas possuem imprecisões que devem ser corrigidas já que a informação continua disponível em canal publico.
A terceira forma normal admite relacionamentos do tipo (0,1) e (0,N) de forma que chaves estrangerias podem ser nulas.