DB контекст не формирует запрос на обновление первичного ключа

@sijuiem · Регистрация: 22.05.2017

Студворк — интернет-сервис помощи студентам

При попытке сохранения изменений значения первичного ключа ошибка. (EF NET 8)

The property 'ТАБЛИЦА.ПОЛЕ_В_ПЕРВИЧНОМ_КЛЮЧЕ' is part of a key and so cannot be modified or marked as modified. To change the principal of an existing entity with an identifying foreign key, first delete the dependent and invoke 'SaveChanges', and then associate the dependent with the new principal.

Например, есть таблица тарифов (ключ - id) и история ставок тарифов (ключ id, dstart) . У истории ставок нет дочерних таблиц. При редактировании в таблице истории ставок существующей записи поля dstart (часть первичного ключа) и сохранении в SaveChanges выходит выше указанное предложение. Как то глупо получается. Надо удалить запись и ввести новую с новой датой. Образно говоря оператор внес информацию, сохранил ее, потом увидел, что ошибся в дате, пытается изменить дату, но ему предлагается удалить все что он ввел и внести информацию заново. Кто что делает в таком случае?

@Andrey-MSK · 20.01.2025, 08:43

Сообщение от sijuiem

Образно говоря оператор внес информацию, сохранил ее, потом увидел, что ошибся в дате, пытается изменить дату, но ему предлагается удалить все что он ввел и внести информацию заново. Кто что делает в таком случае?

Эмммм... Для этого есть UPDATE - вот с ним всё решается оченно просто.

T-SQL
1
2
3
UPDATE MyTable
SET Field01 = N'Поле01', Field02 = N'20250120'
WHERE ID = @id -- ID нужной записи для редактирования.

@sijuiem · 20.01.2025, 08:51 **[ТС]**

Сообщение от Andrey-MSK

Эмммм... Для этого есть UPDATE - вот с ним всё решается оченно просто.

Если бы все хотелось писать sql запросами, то в теме я бы не пометил EF NET. (

@Andrey-MSK · 20.01.2025, 09:09

Сообщение от sijuiem

то в теме я бы не пометил EF NET.

Я вам показал как это делается правильно с точки зрения сервера SQL. Первичный ключ никогда не меняется, он уникален на всей продолжительности жизни БД.
Переведите эту запись на EF - Основные операции с данными. CRUD.

@sijuiem · 20.01.2025, 09:17 **[ТС]**

Сообщение от Andrey-MSK

Первичный ключ никогда не меняется, он уникален на всей продолжительности жизни БД.

Если бы все были согласны с тем, что первичные ключи должны быть неизменяемыми, то все СУБД запрещали бы обновление первичных ключей. Однако это не так.

@Andrey-MSK · 20.01.2025, 09:22

Сообщение от sijuiem

Однако это не так.

Как вы таблицу сделаете - так и будет. Вот так ID будет сам обновляться и никогда не повторится при удалении записей

T-SQL
1
2
3
4
5
6
7
8
9
CREATE TABLE [dbo].[tblEObject](
    [ID_EObject] [int] IDENTITY(1,1) NOT NULL, -- Автоматический ID
    [EObjectName] [nvarchar](200) NULL,
 CONSTRAINT [PK_tblEObject] PRIMARY KEY CLUSTERED 
(
    [ID_EObject] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO

ID должен быть уникальным и назначаться сервером СУБД, никаких ручных правок для него делать не нужно, хотя возможность такая есть...

@sijuiem · 20.01.2025, 09:29 **[ТС]**

Сообщение от Andrey-MSK

Как вы таблицу сделаете - так и будет. Вот так ID будет сам обновляться и никогда не повторится при удалении записей

Вопрос в том, что таблицы уже сделаны, сделаны давно. И да, это не MS SQL.
На ADO.NET с этим проблем вообще ноль.
Но вот EF NET подавай строго неизменяемый primary key. И это проблема.

@Andrey-MSK · 20.01.2025, 09:51

Сообщение от sijuiem

На ADO.NET с этим проблем вообще ноль.

Потому что ADO.NET работает с SQL напрямую.

Добавлено через 7 минут

Сообщение от sijuiem

и история ставок тарифов (ключ id, dstart)

Кто делает в первичном ключе изменяемое поле? Вот пример ключа сделки для ID 85

Code
1
2
85 20250117
85 20250118

Вы ошиблись, и для ID 85 было сделано 3 сделки 20250117 - и что в итоге? Как вы это запишите?
Кто мешал использовать обычный ID таблицы и связь 1-M?

@sijuiem · 20.01.2025, 10:04 **[ТС]**

Сообщение от Andrey-MSK

Потому что ADO.NET работает с SQL напрямую.

А EF NET запросы формирует не напрямую для сервера СУБД? Суть в том что разработчики EF просто решили, что ключи отныне должны быть неизменяемыми. Не удивлюсь, если в будущем этот косяк будет исправлен. Пока же придется реализовывать костыли для обхода "новой реальности". )

Добавлено через 7 минут

Сообщение от Andrey-MSK

Вы ошиблись, и для ID 85 было сделано 3 сделки 20250117 - и что в итоге? Как вы это запишите?
Кто мешал использовать обычный ID таблицы и связь 1-M?

Это частный случай. Понятно что здесь ошибки в проектировании. Если вы будет хранить 20250117 в поле Datetime, то проблем не будет.

Я вам дам другой пример. Тариф ЖКХ и его история, когда не может быть два изменения ставки за один день.
Но при этом сама ставка могла начаться с одного дня, а потом внезапно оказалось что она должна начинаться с другого дня.
Конечно можно сделать искусственный ключ. Но это дополнительное поле раз и дополнительный индекс два. Зачем?

@Andrey-MSK · 20.01.2025, 10:07

Сообщение от sijuiem

Не удивлюсь, если в будущем этот косяк будет исправлен.

Не будет, так как это не косяк EF. Это косяк разработчика БД, не СУБД, а именно БД. К примеру в MS SQL Server можно руками править поле IDENTITY вот такой командой

T-SQL
1
IDENTITY OFF/ON

Но после этого о целостности данных можно забыть...

Добавлено через 57 секунд

Сообщение от sijuiem

Но при этом сама ставка могла начаться с одного дня, а потом внезапно оказалось что она должна начинаться с другого дня.

Вы не читаете?

Сообщение от Andrey-MSK

Кто мешал использовать обычный ID таблицы и связь 1-M?

@sijuiem · 20.01.2025, 10:13 **[ТС]**

Сообщение от Andrey-MSK

Вы не читаете?

Дополнительное поле, дополнительный индекс.

Добавлено через 3 минуты

Сообщение от Andrey-MSK

Но после этого о целостности данных можно забыть...

Не совсем силен в MS SQL, но почему забыть? Отсутствуют каскадные обновления и удаления?
Или IDENTITY OFF отключает первичный ключ? И как часто Вы даете возможность пользователю сделать IDENTITY OFF?

@Andrey-MSK · 20.01.2025, 10:22

Сообщение от sijuiem

Или IDENTITY OFF отключает первичный ключ?

Отключает его автоматическую генерацию и поддержку уникальности.

Сообщение от sijuiem

Дополнительное поле, дополнительный индекс.

Code
1
2
3
4
5
6
7
Table01 ID, Fiedl01, Field02
Table02 ID, ID_Table01, Feld01, Field02
 
Table01.ID -> первичный ключ первой таблицы
Table02.ID -> первичный ключ второй таблицы
 
1-M -> Table01.ID = Table02.ID_Table01

Это стандартная практика связи таблиц, ничего тут лишнего нет и работает быстро, как и задумывалось.

Добавлено через 2 минуты

Сообщение от sijuiem

дополнительный индекс.

А это никак не влияет на БД, от слова совсем... Это даже будет лучше, так как анализатор запросов будет использовать дополнительные индексы для оптимизации плана запроса. Количество индексов на скорость работы никак не влияет. Можете их хоть 100 для таблицы сделать...

@Kulma · 20.01.2025, 10:22

Сообщение от sijuiem

но ему предлагается удалить все что он ввел и внести информацию заново. Кто что делает в таком случае?

Правильно предлагается. Все остальные варианты(костыли) ,с редактированием Primarykey тем более, от лукавого.

Сообщение от sijuiem

Дополнительное поле, дополнительный индекс.

И что ? У вас БД терабайтная , что лишний индекс ее положит в плане производительности?

@Andrey-MSK · 20.01.2025, 10:25

Сообщение от sijuiem

Отсутствуют каскадные обновления и удаления?

А вот про это нужно забыть как про страшный сон. В неумелых руках это бомба замедленного действия...

@Usaga · 20.01.2025, 10:31

Сообщение от Andrey-MSK

А вот про это нужно забыть как про страшный сон. В неумелых руках это бомба замедленного действия...

Я бы не сказал...

@sijuiem · 20.01.2025, 10:33 **[ТС]**

Сообщение от Andrey-MSK

А вот про это нужно забыть как про страшный сон. В неумелых руках это бомба замедленного действия...

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

Добавлено через 2 минуты

Сообщение от Kulma

Правильно предлагается. Все остальные варианты(костыли) ,с редактированием Primarykey тем более, от лукавого.

Не вижу тут лукавого. У таблицы с редактируемым Primary Key НЕТ ДОЧЕРНИХ ТАБЛИЦ. В чем тут могут быть проблемы?
При это чать составного primary key относящаяся к родителю не редактируется.

@Andrey-MSK · 20.01.2025, 10:45

Сообщение от Usaga

Я бы не сказал...

Я ведь уточнил про неумелые руки

Добавлено через 1 минуту

Сообщение от sijuiem

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

EF умеет напрямую работать с запросами SQL. Если вам так хочется, делайте... Но БД лучше перепроектировать...

@Kulma · 20.01.2025, 10:50

Сообщение от sijuiem

У таблицы с редактируемым Primary Key НЕТ ДОЧЕРНИХ ТАБЛИЦ. В чем тут могут быть проблемы?

Не имеет значения, есть дочерние таблицы или нет. Вы же эту таблицу не просто так создавали,
она наверняка участвует в какой-то логике
Идея целостности БД предполагает 1 ключ- 1 запись, для этого собственно и есть первичные ключи, как гарантия соблюдения вышесказанной концепции.
Когда вы отдаете заполнение этого ключа на откуп оператору/пользователю, то всегда существует вероятность
ошибки со всеми вытекающими.
И совершенно не обязательно ключ может быть продублирован , вероятность этого как раз практически нулевая,
учитывая уникальность ключевого поля, а вот ошибка ввода , например случайная смена раскладки клавиатуры,
вполне может быть.

@sijuiem · 20.01.2025, 11:11 **[ТС]**

Сообщение от Andrey-MSK

Но БД лучше перепроектировать...

Скорее всего

@Kulma · 20.01.2025, 11:12

Сообщение от sijuiem

Уже демагогия какая то пошла...

Отнюдь.
Соглашусь с Andrey-MSK - это бомба замедленного действия.
Для небольших проектов наверное удобно , но эти процессы (каскадные удаления и обновления) должны
быть контролируемы разработчиком.
Вот представьте : есть некая компания , работающая с рядом поставщиков.
В один прекрасный момент кто-то из поставщиков прекращает сотрудничество и сливается,
а один сердобольный манагер решает удалить его запись из базы, дабы глаза не мозолил.
Только он не подумал, да и надо ли ему, что по поставщику есть какая-то
история- приходы/расходы/финансовые движения и т.д.
Догадываетесь , что произойдет при установленном дефолтно каскадном удалении и каким
"добрым словом" разраба вспомнит бухгалтерия, когда грохнется вся документальная история в базе,
привязанная к удаленной записи ?? ))

Новые блоги и статьи Все статьи Все блоги /
Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .	Запрет удаления строк ТЧ документа при определенном условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .
Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .

@sijuiem 0 / 0 / 0 Регистрация: 22.05.2017 Сообщений: 37

	DB контекст не формирует запрос на обновление первичного ключа 17.01.2025, 22:42. Показов 3811. Ответов 41 Метки нет (Все метки) При попытке сохранения изменений значения первичного ключа ошибка. (EF NET 8) The property 'ТАБЛИЦА.ПОЛЕ_В_ПЕРВИЧНОМ_КЛЮЧЕ' is part of a key and so cannot be modified or marked as modified. To change the principal of an existing entity with an identifying foreign key, first delete the dependent and invoke 'SaveChanges', and then associate the dependent with the new principal. Например, есть таблица тарифов (ключ - id) и история ставок тарифов (ключ id, dstart) . У истории ставок нет дочерних таблиц. При редактировании в таблице истории ставок существующей записи поля dstart (часть первичного ключа) и сохранении в SaveChanges выходит выше указанное предложение. Как то глупо получается. Надо удалить запись и ввести новую с новой датой. Образно говоря оператор внес информацию, сохранил ее, потом увидел, что ошибся в дате, пытается изменить дату, но ему предлагается удалить все что он ввел и внести информацию заново. Кто что делает в таком случае? 0