|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Server Version: WI-V3.0.3.32891 Firebird 3.0 Тестовый пример Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
Запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
Выдает ошибку Invalid insert or update value(s): object columns are constrained - no 2 table rows can have duplicate column values. violation of PRIMARY or UNIQUE KEY constraint "PK_TEST_MERGE" on table "TEST_MERGE". unknown ISC error 335545072. Источник в Megre требует уникальный набор строк, используя group by запрос выполняется. Для FB2.5 ошибки не было. Это ошибка или изменение поведения? В доке для FB3: "Каждая запись источника используется для обновления (предложение UPDATE) или удаления (предложение DELETE) одной или более записей цели, или вставки (предложение INSERT) записи в целевую таблицу, или ни для того, ни для другого." ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 10:12 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Молочный Александр, стабильный курсор не позволяет запросу видеть собственные изменения. Так что group by тут как раз то, что нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 10:17 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
hvlad, т.е. теперь будет такое поведение? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 10:30 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Молочный Александр, да, теперь есть такое, правильное, поведение. См. http://tracker.firebirdsql.org/browse/CORE-3362 и связанные с ним тикеты ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 10:44 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
hvlad, получается теперь, что если в источнике не уникальная строка всегда будет insert, update не будет выполнятся. тогда наверно надо в доке уточнить описание merge ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 11:07 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Молочный Александрполучается теперь, что если в источнике не уникальная строка всегда будет insert, update не будет выполнятсяНе получается. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 11:12 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Молочный Александресли в источнике не уникальная строка всегда будет insert, update не будет выполнятся. Когда-нибудь и этот баг поправят и такой источник будет вызывать ошибку. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 12:47 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
hvladда, теперь есть такое, правильное, поведение. См. http://tracker.firebirdsql.org/browse/CORE-3362 и связанные с ним тикеты Влад, а какое "правильное" поведение должно быть у команды UPDATE OR INSERT INTO MATCHING (<PRIMARY KEY>)? если при попытке выполнить сию кляузу я то же получаю Violation of PRIMARY or UNIQUE KEY constraint Как такое может происходить? Сервер 3.0.3.32900 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 12:48 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Maxim KovalenkoВлад, а какое "правильное" поведение должно быть у команды UPDATE OR INSERT INTO MATCHING (<PRIMARY KEY>)? если при попытке выполнить сию кляузу я то же получаю Violation of PRIMARY or UNIQUE KEY constraint Как такое может происходить? Сервер 3.0.3.32900Хотелось бы с примером. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 13:18 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Гм, в том то и дело, что ошибка плавающая. Что есть: 1. Таблица, куда вставляется запись 2. на триггере AI дергается каскад из пары процедур 3. и на крайней процедуре и вызывается UPDATE OR INSERT INTO как результат ошибка. я смотрел по диагонали Пашины скрипты в тиките, очень уж у него все кучеряво. Может конечно это ближе к Нарушение PK при интенсивном обмене данными между таблицами. Не могу понять причину. Самое паршивое, что это на распределенной системе при приеме порции данных периодически возникает такая бяка. Программа обмена, если возникает ошибка при приеме файла с данными, в следующий раз снова пытается загрузить этот же файл, но на след. раз принимается нормально. т.е. воспроизводимого примера пока получить не удается. Может есть мысли как такое поймать? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 13:36 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Молочный Александрполучается теперь, что если в источнике не уникальная строка всегда будет insert, update не будет выполнятся. тогда наверно надо в доке уточнить описание merge Уникальность здесь вообще не причём. MERGE производит соединение RIGHT JOIN целевой таблицы и источника. Если запись соответствующая условию соединения найдена в целевой таблице, то для неё выполняется UPDATE (или DELETE), ели не найдена, то INSERT. Причём вновь вставленные записи не видны в результатах соединения (начиная с 3.0 и это по стандарту). Поэтому никаких оговорок на этот счёт в документации нет. Наоборот, есть оговорки в документации 2.5 потому что в нём это поведение было не стандартным. И вообще по стандарту MERGE должен выдавать ошибку, если под условие соединения источника и целевой таблицы попадает более 1 записи, но сейчас это не делается. Т.е. одна и та же запись по стандарту не может обновлена несколько раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 13:43 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Maxim KovalenkoКак такое может происходить? Параллельные транзакции, кривые параметры изоляции, неправильная система генерации ключей, сборка мусора не успевает. Плюс любая комбинация из вышеназванного. Ты бы ошибку целиком для начала прочитал. Там есть и название ограничения и значения, которые его нарушают. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 14:06 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
hvladХотелось бы с примером. UPDATE OR INSERT одной и той же записи из параллельных транзакций гарантированно приводит к ошибке в одной из них. У отсутствующей записи это будет нарушение ключа, у наличествующей - конфликт обновления. И это штатная механика. Но оптимисты думают, что оно - таблетка от конфликтов. Зря. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 14:27 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovсборка мусора не успеваетДа ну ? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 14:29 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov из параллельных транзакций Что есть парралельная транзакция? Если одна транзакция влезает в другую и может ей помешать, то это значит, что "осетрина тухлая". Прошу не путать с деадлоком! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 15:52 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
SQL2008, какой ещё дедлок? Где нашёл ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 15:55 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
SQL2008Что есть парралельная транзакция? То, чего нет в MS SQL: транзакция, выполняющаяся одновременно с данной. Неважно в той же или другой сессии. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 16:00 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, ты не дописал "То, чего нет в MS SQL: транзакция, выполняющаяся одновременно с данной " в одном и том же коннекте. В разных коннектах у них-то транзакции вполне параллельно существуют. Кроме того, мне кажется, что вопрос SQL2008Если одна транзакция влезает в другую и может ей помешать, то это значит, что "осетрина тухлая". скорее относится к тухлости блокировочного сервера MS SQL. В ФБ никто не мешает менять прочитанные другими транзакциями данные, и ни о какой "тухлости" речи быть не может. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 16:42 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
kdv скорее относится к тухлости блокировочного сервера MS SQL. В ФБ никто не мешает менять прочитанные другими транзакциями данные, и ни о какой "тухлости" речи быть не может. Насчет тухлости MS SQL это напрасно. Я им не защитник, но там реализовано все нормально. После 2005 сервера, когда пофиксили деадлоки, стало совсем нормально. авторТо, чего нет в MS SQL: транзакция, выполняющаяся одновременно с данной. Неважно в той же или другой сессии. Это сильно сказано! Т.е вы полагаете, что в MS SQL нет возможности работать в транзакции, выполняющейся одновременно с другой? Даже в одной сессии? Я правильно вас понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 17:05 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
SQL2008, в ms sql нет больше одной транзакции в одном коннекте. речь об этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 17:21 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov UPDATE OR INSERT одной и той же записи из параллельных транзакций гарантированно приводит к ошибке в одной из них. У отсутствующей записи это будет нарушение ключа, у наличествующей - конфликт обновления. И это штатная механика. Но оптимисты думают, что оно - таблетка от конфликтов. Зря. Сбой при вставке записи в таблице "SGM" . ID_SGM = 2253453392155252. Код: plsql 1. 2. 3. 4. 5.
Нда разобрался. Тут действительно была именно такая ситуация. Докапываться пришлось долго Т.е. что произошло. в одной относительно длинной транзакции (1минута с копейками) вставлялись данные, которые на каскаде, через UPDATE OR INSERT создали в таблице TSTTN запись с ID 2252130937471591 и, забегая вперед, никакого конфликта обновления не вызвали ибо в другой короткой транзакции вставляли в таблицу SGM запись и то же на каскаде дело дошло до UPDATE OR INSERT в таблице TSTTN и при коммите вылезло сообщение об ошибке (выше). Ну и естественно ролбек. А вот почему 1 "длинная" ничего не сказала и все прошло штатно, потому что к моменту комита 2-ая уже отвалилась? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 17:29 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
Maxim Kovalenko, ограничения в Firebird проверяются сразу, не по коммиту. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 17:49 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
SQL2008Т.е вы полагаете, что в MS SQL нет возможности работать в транзакции, выполняющейся одновременно с другой? Да, я так полагаю, основываясь на твоём удивлении в отношении термина "параллельная транзакция" и какого-то бреда насчёт "влезает в другую и может ей помешать". Если в каком-то сервере одна транзакция совершенно никак не может помешать другой, значит выполняются они строго последовательно. Ну а MS - чисто из ника. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 18:10 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
kdvSQL2008, в ms sql нет больше одной транзакции в одном коннекте. речь об этом. Блин! А мужики то не знают ! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 19:55 |
|
ошибка при использовании Merge в FB3
|
|||
---|---|---|---|
#18+
SQL2008После 2005 сервера, когда пофиксили деадлоки, стало совсем нормально. Я не хочу вникать в дискуссию аб осетрине, но таки позволю себе напомнить катехизис. Деадлок - это когда одна транзакция апдейтит запись а, а потом запись бе, а другая сначала бе, а потом а. И тут-то оне и встают в озадаченную позу. Обеи. Потому он и деад, сиречь намертво. И пофиксить его, дедлока, нет ну просто никакой возможности, акромя как по классике одну из транзакций откатить, и то только ежели оне обеи wait. Все остальные упоминания дедлока всуе есть еретичество и апокрифы, со всеми вытекающими последствиями в плане запудривания мозгов друг другу спорящими, каждый из которых долдонит о своём, не слыша собеседника. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 21:32 |
|
|
start [/forum/topic.php?fid=40&msg=39609783&tid=1561219]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 174ms |
0 / 0 |