это обойти?
Надо думать, какой-нибудь constraint нарушэн. Хотя, бывает, что deadlock какой-нибудь. В первом случае — подумать, почему там такой constraint, что имели в виду его создатели и как так получилось, что он нарушэн. Во втором — повторить транзакцыю, deadlock в SQL это норма.
бога ради, почему тут бывают исключенгия?
принято, скжите, пожалуйста, INSERT INTO mdm.entity values(defaults);
Судя по косвенным данным (что вы подумали на сиквенсы) — у вас значения PK повторились. Это бывает, когда в таблицу вставляют значения мимо сиквенсов/дефолтов — и не обновляют потом сиквенс так, чтобы он их пропустил.
Чаще всего — из-за какой-то заливки датасетов другими методами, чем дефолты или частичных восстановлений из дампов.
Уже проверяли, max(id) на обеих таблицах меньше чем значения которые выдают генераторы. Что делает случай несколько любопытным...
Я видел, да. Так небось сейчас всё вставится.
Если, конечно, и правда вставляется так, как утверждается.
Ваша мысль понятна, не не имеет корреляции с реальностью, скажите, пожалуйста, если однозначный формат аргументации?
Конечно, нельзя исключать дохлый индэкс... Но вариант с объедками предыдущих данных более вероятен.
Формат чего? Не распарзил как-то.
вы вуалируете в ответе
Кстати говоря, max(id) — не совсем однозначный тэст, если там автокоммит отключен... Но вряд ли это объяснит проблемы с сиквенсами (мне, правда, пока что дажэ неизвестные).
Стараюсь отвечать с формальной корректностью ответов. Это приводит к многословности, и жэланию использовать побольшэ сокращений.
Обсуждают сегодня