Hi,
sp_MSrestoresavedforeignkeys do not restore FK which relay on unique index.
Here is an example :
I have 2 tables With a FK between them. The FK relays on unique index.
(parent table tblACConfigurations is replicated) :
CREATE TABLE [dbo].[tblACConfigurations](
[iConfigurationId] [INT] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[iClientId] [INT] NOT NULL,
[vcConfigurationDesc] [VARCHAR](255) NULL,
CONSTRAINT [PK_tblACConfigurations] PRIMARY KEY NONCLUSTERED
(
[iConfigurationId] ASC
))
CREATE UNIQUE CLUSTERED INDEX [idx_tblACConfigurations_ConfigClient] ON [dbo].[tblACConfigurations]
(
[iConfigurationId] ASC,
[iClientId] ASC
)
GO
CREATE TABLE [dbo].[tblLocationConfigurations](
[iLocationId] [int] NOT NULL,
[iConfigurationId] [int] NOT NULL,
[iClientId] [int] NOT NULL,
CONSTRAINT [PK_tblLocationConfigurations] PRIMARY KEY CLUSTERED
(
[iLocationId] ASC,
[iConfigurationId] ASC,
[iClientId] ASC
))
GO
ALTER TABLE [dbo].[tblLocationConfigurations]
ADD CONSTRAINT [FK_tblLocationConfigurations_iConfigurationId_iClientId_tblACConfigurations_iConfigurationId_iClientId] FOREIGN KEY ([iConfigurationId], [iClientId]) REFERENCES [dbo].[tblACConfigurations] ([iConfigurationId], [iClientId])
ON DELETE NO ACTION ON UPDATE NO ACTION NOT FOR REPLICATION;
Go
When pushing a snapshot sql server executes the following :
EXEC dbo.sp_MSdropfkreferencingarticle @destination_object_name = N'tblACConfigurations', @destination_owner_name = N'dbo'
and then
exec sys.sp_MSrestoresavedforeignkeys
The problem is that the FK is not restored. The cause of this problem is that before sqlServer (in sp_MSrestoresavedforeignkeys) restores a FK it does some checks :
1.Is the foreign key already present?
2.Is the referencing table present?
3.Is the referenced table present?
4.Are all the referencing columns present?
5.Are all the referenced columns present?
6.Is there a candidate referenced index key present? - This is the reason my FK is not restored. Not all columns in the FK include in sys.key_constraints.
Is it a bug ?
BTW : I understand the design is bad, but it is an old database.
Regards, Asi Pesa
