Na podstawie twoich przykładów spróbowałem również:
- Upuść i odtwórz klucz obcy.
- Upuść i utwórz ponownie tabelę.
Potem zauważyłem coś w poleceniu:
NOT FOR REPLICATION
Wygląda na to, że jeśli ograniczenie jest tworzone z opcją NIE DO REPLIKACJI, zawsze nie jest zaufane.
Cytując z książek online :
Wygląda na to, że IS_NOT_TRUSTED
ustawienie jest istotne tylko dla replikacji pod wpływem IS_NOT_FOR_REPLICATION
. Myślę, że dopóki ograniczenie jest wymuszane na serwerze, na którym pracujesz, powinno być w porządku. Więc poszedłem dalej i potwierdziłem to:
SELECT name, is_disabled, is_not_trusted
FROM sys.foreign_keys
WHERE name = 'FK_Product_ProductKeyId'
name is_disabled is_not_trusted
FK_Product_ProductKeyId 0 1
INSERT INTO dbo.Sale VALUES (2, GETDATE(), 1.00)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Product_ProductKeyId". The conflict occurred in database "_Scratch", table "dbo.Product", column 'ProductKeyId'.
The statement has been terminated.
Jeśli nadal chcesz widzieć IS_NOT_TRUSTED = 0
dla spokoju ducha, po prostu odtwórz klucz obcy bez NOT FOR REPLICATION
.
W przypadku, gdy ci z was się zastanawiają, zweryfikowałem ten sam wpływ na ograniczenia CHECK.