Обновление первичных ключей с помощью LINQ

Question

В настоящее время я работаю над средой песочницы на основе двух баз данных, расположенных на разных серверах. То, что я намереваюсь сделать, это позволить моим клиентам вносить изменения на тестовом сервере, а затем после их одобрения я могу просто нажать кнопку и импортировать данные в мою текущую базу данных.

До сих пор мне удалось перенести данные по двум базам данных, но то, что я хотел бы сделать, это изменить первичные ключи на тестовом сервере, чтобы они соответствовали тем, которые хранятся в реальном времени (если мне нужны резервные копии, и поэтому я может делать проверки, чтобы копировать одну и ту же информацию несколько раз).

До сих пор я попытался это решение:

DT_SitePage OldPage = new DT_SitePage 
       { 
        PageID = SP.PageID 
       }; 

       DT_SitePage NewPage = new DT_SitePage 
       { 
        PageID = int.Parse(ViewState["PrimaryKey"].ToString()) 
       }; 

       Sandbox.DT_SitePages.Attach(NewPage, OldPage); 
       Sandbox.SubmitChanges(); 

Однако я получаю ошибку:

***Value of member 'PageID' of an object of type 'DT_SitePage' changed. 
A member defining the identity of the object cannot be changed. 
Consider adding a new object with new identity and deleting the existing one instead.*** 

Есть ли вообще в LINQ, чтобы избежать этой ошибки и заставить базу данных, чтобы обновить это поле ???

Большое спасибо

Answer 1

Почему вы не использовать запас резервное копирование/восстановление функциональности поставляется БД производитель?

Совершенно логично понять, что высокоуровневые инструменты ORM не позволят вам изменить первичный ключ записи, поскольку они идентифицируют запись только по ее первичному ключу.

Вы должны рассмотреть возможность прямого запроса UPDATE к БД из вашего кода.

И вообще, смена первичного ключа - плохая идея, что мешает вам с INSERT с ее нужной стоимостью в первую очередь?

Answer 2

Как сказано, изменение первичных ключей обычно является чем-то, что вы не хотите делать. Если Linq-to-sql не будет иметь раннего предупреждения, ваша RDBMS, вероятно, будет жаловаться (сервер SQL делает!). Особенно, когда записи связаны с ограничениями внешнего ключа, обновление первичных ключей не является тривиальным.

В сценариях с несколькими базами данных чаще используется некоторая «глобальная» уникальная идентификация, для которой могут выполняться GUID. Может быть, ваши данные могут быть идентифицированы альтернативным способом? (Например, когда у двух пользователей одинаковое имя, они считаются идентичными).

Если вам не нужно сохранять идентичные структуры базы данных, вы можете рассмотреть возможность использования дополнительного поля в тестовой базе данных для хранения «живого» первичного ключа.

Here это сообщение с большим количеством полезных мыслей.