4 обходных пути, когда уникальное ограничение не позволяет вставить новую запись в SQL Server

SQL Server Решения 29 сентября, 2025
Поделись сейчас:

Если вам не удалось вставить новую запись в таблицу из-за ограничения уникальности, обязательно прочитайте эту статью. Это поможет вам решить эту проблему.

В этой статье мы представим 4 метода решения проблемы, когда вам не удается вставить новую запись, поскольку она нарушает уникальное ограничение таблицы в SQL Server.

Реальный случай:

Теперь давайте посмотрим реальный случай. У нас есть база данных с именем «Продукт» и таблица с именем «DataNumenТовар» в базе данных. В таблице есть два поля, т. е. «ProductId» и «ProductName», с типами данных «int» и «varchar» соответственно. А «ProductId» — это первичный ключ с уникальным ограничением.

В настоящее время в таблице есть несколько записей, как показано ниже:Записи в таблице "DataNumenПродукт"

Рисунок 1. Записи в таблице «DataNumenПродукт"

Предположим, что для базы данных есть два администратора баз данных, т. е. Джим и Том. Однажды Джим удалил первую запись в таблице, как показано ниже:

DELETE FROM DataNumenProduct
WHERE ProductId=1;

На второй день Том вставил в таблицу новую запись, которая имеет тот же первичный ключ, что и удаленная запись, как показано ниже:

INSERT INTO DataNumenProduct
VALUES(1,'DataNumen OutLook Repair');

Итак, наша таблица имеет следующие записи, как показано ниже:

Обновлены записи в таблице "DataNumenТовары"

Рис. 2. Обновленные записи в таблицеDataNumenТовары"

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

Обходной путь 1: изменить первичный ключ новой записи, чтобы предотвратить конфликт

Мы можем изменить первичный ключ вставляемой записи на новое значение, отличное от всех существующих записей в таблице. Возьмем приведенный выше случай в качестве примера: для вставляемой записи мы можем изменить значение первичного ключа с 1 до 5. Затем мы можем восстановить новую сгенерированную запись обратно в таблицу, как показано ниже:

INSERT INTO DataNumenProduct VALUES(5, 'DataNumen Access Repair');

Ниже приведены итоговые записи в таблице:Итоговые записи в таблице»DataNumen Товары"

Рисунок 3 Окончательные записи в таблицеDataNumen Товары"

Обходной путь 2: изменить первичный ключ существующей записи, чтобы предотвратить конфликт

  1. Во-первых, нам нужно обновить значение первичного ключа существующей записи, что может вызвать конфликт, как показано ниже:
UPDATE DataNumenProduct
SET ProductId = 6
WHERE ProductId = 1;

Ниже приведены обновленные записи в таблице:

Обновлены записи в таблице "DataNumen Товары"

Рис. 4. Обновленные записи в таблицеDataNumen Товары"

  1. Затем мы можем восстановить удаленную запись обратно в таблицу, как показано ниже:
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair ');

Теперь давайте посмотрим окончательную версию, как показано ниже:

Окончательные записи в таблице «DataNumen Товары"

Рисунок 5 Окончательные записи в таблицеDataNumen Товары"

Обходной путь 3: отключите уникальный темп ограниченияrarили через SQL

  1. Чтобы решить эту проблему, мы можем удалить ограничение первичного ключа «pk» в таблице tempo.rarили, как показано ниже:
ALTER TABLE DataNumenProduct
DROP CONSTRAINT pk;
  1. Затем мы можем вернуть удаленную запись в таблицу, как показано ниже:
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair');

Теперь посмотрим записи в таблице:

Обновлены записи в таблице "DataNumen Товары"

Рис. 6. Обновленные записи в таблицеDataNumen Товары"

  1. Затем, поскольку две записи имеют одинаковые значения первичного ключа, нам нужно изменить одну из них, чтобы предотвратить конфликт, как показано ниже:
UPDATE DataNumenProduct SET ProductId = 5
WHERE ProductName = 'DataNumen Outlook Repair';
  1. Наконец, мы добавляем обратно в таблицу ограничение первичного ключа «pk», как показано ниже:
ALTER TABLE DataNumenProduct
ADD CONSTRAINT pk PRIMARY KEY(ProductId);

Теперь в таблице есть несколько записей, как показано ниже:

Обновлено содержимое в таблице «DataNumen Товары"

Рис. 7. Обновленное содержимое таблицыDataNumen Товары"

Обходной путь 4: отключите уникальный темп ограниченияrarили через SQL Server Студия управления:

  1. Во-первых, мы удаляем ограничение первичного ключа «pk» в таблице через графический интерфейс, как показано ниже:

Удалите ограничение первичного ключа «pk» через графический интерфейс.

Рис. 8. Удаление ограничения первичного ключа «pk» через графический интерфейс

  1. Затем мы вставляем удаленную запись в реальном случае в таблицу, как показано ниже.
INSERT INTO DataNumenProduct
VALUES(1, 'DataNumen Access Repair');

Теперь в таблице есть несколько записей, как показано ниже:

Обновлено содержимое в таблице «DataNumen Товары"

Рис. 9 Обновленное содержимое в таблицеDataNumen Товары"

  1. Затем мы изменяем значение первичного ключа существующей записи в таблице, как показано ниже:
UPDATE DataNumenProduct
SET ProductId = 5
WHERE ProductName = 'DataNumen Outlook Repair';
  1. Наконец, мы добавим обратно ограничение первичного ключа «pk» в таблицу через графический интерфейс, как показано ниже:Добавить обратно ограничение первичного ключа «pk» через графический интерфейс

Рис. 8. Добавление обратно ограничения первичного ключа «pk» через графический интерфейс

Решить SQL Server Повреждение базы данных

Кроме уникальных ограничений, SQL Server коррупция также очень распространенная проблема, раздражающая администраторов баз данных. Обычно мы можем использовать SQL Server встроенные команды для устранения повреждений. Однако если они не работают, то можно прибегнуть к каким-то сторонним SQL Server средства восстановления данных.

Об авторе:

Джим Ху — эксперт по восстановлению данных в DataNumen, Inc., которая является мировым лидером в области технологий восстановления данных, включая Доступ к ремонту и dbf ремонт программных продуктов. Для получения дополнительной информации посетите www.datanumen.com

Поделись сейчас:

Комментарии закрыты.