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, 11:22

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

И как часто Вы даете возможность пользователю сделать IDENTITY OFF?

Никогда. Эта возможность только для администратора и используется очень редко в технических целях при обслуживании БД.

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

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

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

Логика сводится лишь к тому чтобы не было двух записей по одному родителю за определенную дату. И все.
Я же уже написал, что логика таблицы хранить историю определенных показателей.
В этом контексте изменение пользователем части первичного ключа вполне допустимо.
От того что я сделаю искусственный ключ, а текущий примари вынесу в просто уникальный ничего не поменяется. Пользователь также не сможет внести внести два одинаковых значения составного ключа.
Суть в том, что удалив запись и создав ее заново - так можно, а просто изменить часть ключа - так нельзя. Но по факту результат получается одним и тем же.

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

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

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

Запрет каскадных удалений в базе и нет проблемы.

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

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

Догадываетесь , что произойдет при установленном дефолтно каскадном удалении и каким

А что есть такие СУБД где каскадное удаление по умолчанию разрешено?

@Andrey-MSK · 20.01.2025, 11:36

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

А что есть такие СУБД где каскадное удаление по умолчанию разрешено?

Нет, но возможность очень соблазнительная, да вы и сами про неё упомянули...

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

@Andrey-MSK · 20.01.2025, 11:42

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

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

Сделайте из этих полей отдельный уникальный индекс, а первичным сделайте ID, и проблема будет решена...

@IamRain · 20.01.2025, 11:45

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

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

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

В этом контексте изменение пользователем части первичного ключа вполне допустимо.

В контексте СУБД Primary Key - это уникальный идентификатор, который позволяет быстро "зацепиться" за нужную запись.
Поэтому изменение идентификатора нежелательно. Паспорт вы тоже раз в месяц меняете? - аналогия.

@Andrey-MSK · 20.01.2025, 11:46

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

Делов то.

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

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

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

В контексте СУБД Primary Key - это уникальный идентификатор, который позволяет быстро "зацепиться" за нужную запись.
Поэтому изменение идентификатора нежелательно. Паспорт вы тоже раз в месяц меняете? - аналогия.

Сравнить паспорт, с изменением даты в записи, например, хронологии показаний прибора учета. Да вы гений аналогий? ))

@IamRain · 20.01.2025, 11:59

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

Сравнить паспорт, с изменением даты в записи, например, хронологии показаний прибора учета.

Если дата в записи - часть PK, это очень точная аналогия. А лепить БД через *опу - создавать себе ненужные проблемы. Вам заняться больше нечем? - на вопрос дали ответ, удалите и создайте по новой.
Любите секас сидя - занимайтесь

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

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

Сделайте из этих полей отдельный уникальный индекс, а первичным сделайте ID, и проблема будет решена...

На работающих уже базах скорее всего не вариант.
Малой кровью - это невидимое удаление и вставка копии удаленной записи.

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

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

А лепить БД через *опу - создавать себе ненужные проблемы.

Слеплено, то что работает уже 15 лет. Это ли не показатель, что слеплено по факту то неплохо?

@Andrey-MSK · 20.01.2025, 12:15

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

На работающих уже базах скорее всего не вариант.

Чего это вдруг? Запросом делается копия исходной таблицы, создаётся новая с нужной структурой, переносятся данные в неё из исходной, старая удаляется, новая переименовывается.

Добавлено через 4 минуты
sijuiem, Вот один из примеров как меняется структура таблицы на рабочей БД

T-SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/* To prevent any potential data loss issues, you should review this script in detail before running it outside the context of the database designer.*/
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
ALTER TABLE dbo.tblTest_001 ADD
    NewName nvarchar(50) NULL
GO
ALTER TABLE dbo.tblTest_001 SET (LOCK_ESCALATION = TABLE)
GO
COMMIT

@IamRain · 20.01.2025, 12:24

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

Это ли не показатель, что слеплено по факту то неплохо?

Нет, конечно. Возраст - никогда не показатель. Это как говорить, что разработчик с опытом в 20 лет, в 2 раза лучше разработчика с опытом в 10 лет, или это 10x к разработчику с опытом в 2 года. На деле, неизвестно, что там осталось от разработчика, может ничего и не осталось уже.

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

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

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

Нет, конечно. Возраст - никогда не показатель. Это как говорить, что разработчик с опытом в 20 лет, в 2 раза лучше разработчика с опытом в 10 лет, или это 10x к разработчику с опытом в 2 года

Можно без ~~тупых~~ аналогий?

@IamRain · 20.01.2025, 12:57

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

Можно без тупых аналогий?

Ответ на вопрос вам уже дали, зачем вы продолжаете беседу?

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

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

то что работает уже 15 лет. Это ли не показатель, что слеплено по факту то неплохо?

Как раз-таки напротив, возраст может говорить о том, что это сраное легаси, закостенелое (аля "работает - не трогай") во многих местах.
С большим количеством техдолга. Намеки на это мы уже увидели.

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

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

Вот один из примеров как меняется структура таблицы на рабочей БД

А для Firebird можно?

@Andrey-MSK · 20.01.2025, 13:13

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

А для Firebird или MySQL можно?

Язык SQL одинаковый для всех СУБД, различия лишь в наворотах самой СУБД, её внутренних функциях и переменных состояния.

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

Запросом делается копия исходной таблицы, создаётся новая с нужной структурой, переносятся данные в неё из исходной, старая удаляется, новая переименовывается.

Забыл написать. Это всё делается в рамках одной транзакции, чтобы в случае чего вернуть БД в нормальное состояние. И в режиме БД ReadOnly, а ещё лучше в монопольном, если последнее - то всех активных пользователей отключит, БД перейдёт в монопольный режим, вы запустите запрос, он всё сделает, и потом включаете нормальный режим работы БД. Пользователи даже не поймут что произошло, так как для них всё как работало, так и будет работать с новой версией.

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

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

вы запустите запрос

Его конечно нужно будет оттестировать на тестовом сервере, перед запуском на боевом.

@Usaga · 24.01.2025, 08:40

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

Язык SQL одинаковый для всех СУБД, различия лишь в наворотах самой СУБД, её внутренних функциях и переменных состояния.

Язык один, но диалекты разные.

@Andrey-MSK · 24.01.2025, 08:43

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

Язык один, но диалекты разные.

Ну как бы я об этом и сказал

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

различия лишь в наворотах самой СУБД, её внутренних функциях и переменных состояния.

@Usaga · 24.01.2025, 09:07

Andrey-MSK, диалект это не наворот. Это диалект. Похожее, но не точно написание одного и того же.

@Wolfdp · 24.01.2025, 09:57

Не по теме:

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

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

Технически это можно провернуть. Правда до такого рекомендуется не доводить, потому как за программистом тут же выезжают дементоры из Азкабана. XD

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

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

+1

Навыгребал из-за них кучу проблем. Самая элементарная: БД разростается, всё скинули на каскадное удаление. Через некоторое время прилетает баг "удаление занимает дофига времени", ещё через время уже прилетает критикал "удаление падает с таймаутом". Отдельный челендж, когда это удаление критично и нельзя просто пометить "удалено" и забить.

Проблема номер два: ты не чекаешь что удаляешь. Т.е. удалил запись ТаблицаА, а там потянулу записи из ТаблицыВ, которые нельзя удалять (например не хватает прав). Как ты про это узнаешь? Правильно, когда прилетит внеочередной баг от QA месяца так через три-четыре.

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

Чего это вдруг? Запросом делается копия исходной таблицы, создаётся новая с нужной структурой, переносятся данные в неё из исходной, старая удаляется, новая переименовывается.

Старую рекомендую удалить через месяц-другой. На всякий пусть поваляется рядом некоторое время.

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

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

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

Потому как "история" и "один-к-одному" у меня в голове не складываются. Обычно есть таблица с элементами, и таблица истории изменений, которая ссылается на таблицу элементов "один-ко-многим". Причем за правило береться что ЛЮБОЕ изменение порождает новую запись в таблице истории, вне зависимости от того правили критичную инфу или не очень.

Поэтому либо не правильно организовано, либо не понял задум.

@sijuiem · 28.01.2025, 14:01 **[ТС]**

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

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

Простейший вариант тариф и его история.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
class TARIFF
{
    [Key]
    public int ID_TARIFF { get; set; }
    [Required]
    public string NAME { get; set; }
  
    [InverseProperty("ID_TARIFFNavigation")]
    public virtual ICollection<TARIFFDETAIL> TARIFFDETAIL { get; set; } = new List<TARIFFDETAIL>();
}
 
 
 
class TARIFFDETAIL
{
    [Key]
    public int ID_TARIFF { get; set; }
 
    [Key]
    [Column(TypeName = "DATE")]
    public DateTime DSTART { get; set; }
 
    [Column(TypeName = "DECIMAL(15,2)")]
    public decimal RATE { get; set; }
 
    [ForeignKey("ID_TARIFF")]
 
    [InverseProperty("TARIFFDETAIL")]
    public virtual TARIFF ID_TARIFFNavigation { get; set; }
}

Тариф и его история.
Пользователь при вводе новой записи в историю тарифа (в таблицу TARIFFDETAIL) ошибается с датой и сохраняет запись. Затем хочет исправить ее на правильную дату.

В ADO NET - пожалуйста - нет проблем.

В EF NET Core - ошибка. Сначала удали, а затем введи заново.

Конечно можно сделать искусственный ключ для TARIFFDETAIL и ограничение на уникальность для связки ID_TARIFF,DSTART, но что это дает физически, кроме лишнего поля и еще одного индекса?

А еще при этом нельзя будет сделать лаконичный Context.TARIFFDETAIL.Find(ID_TARIFF,DSTA RT)

Новые блоги и статьи Все статьи Все блоги /
Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .	Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .

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

	DB контекст не формирует запрос на обновление первичного ключа 17.01.2025, 22:42. Показов 4662. Ответов 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

@Usaga 14733 / 9507 / 1363 Регистрация: 21.01.2016 Сообщений: 35,869
	24.01.2025, 09:07
	Andrey-MSK, диалект это не наворот. Это диалект. Похожее, но не точно написание одного и того же. 1