Isso é mais uma busca por informações do que um pedido de ajuda...
Estou atualizando alguns bancos de dados antigos (rodando no sql 2005 e nível de compatibilidade 70, suspeito que estejam online desde o sql 6.5) para me livrar de alguns servidores antigos e implantar o SQL Server 2012 ou 2014.
Eu tive que lidar com alguns agrupamentos SQL agora sem suporte, então larguei alguns índices e chaves estrangeiras. Ao tentar restaurá-los, fui interrompido por este erro:
Msg 1778, Nível 16, Estado 0, Linha 2
A coluna 'dbo.Table1.IDColumn' não é o mesmo tipo de dados que a coluna de referência 'Table2.ColumnFK' na chave estrangeira 'Foreign_key'.
O primeiro campo é declarado como varchar(8)e o segundo é um char(8)para que a mensagem esteja correta.
Estou fazendo todos os testes em uma cópia, então verifiquei novamente no banco de dados de produção e a chave estrangeira está lá, vinculando um charcampo a outro varchar.
Ao fazer o script da restrição, obtive isso (esse é o script que está dando erro):
ALTER TABLE [dbo].[Table2]
WITH NOCHECK ADD CONSTRAINT [Foreign_key]
FOREIGN KEY([ColumnFK]) REFERENCES [dbo].[Table1] ([IDColumn])
GO
ALTER TABLE [dbo].[Table2]
NOCHECK CONSTRAINT [Foreign_key]
GO
Encontrei uma resposta no SO afirmando que não é possível ter uma chave estrangeira usando 2 colunas com tipos de dados diferentes, mas uma solução alternativa é fornecida para que o problema não seja crítico.
A questão é: já foi permitido criar um relacionamento em campos com diferentes tipos de dados sem truques? Havia algum tipo de 'compatibilidade' entre char e varchar?
A resposta deve ser um óbvio 'sim, é possível', mas não consigo encontrar nenhuma evidência afirmando que esse comportamento é (era?) permitido e/ou esperado: eu tenho a chave estrangeira no lugar, mas não deve ser possível criá-lo.