|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
В FB 2.5.8 имею следующие две таблицы: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Обновляю вторую таблицу данными из первой: Код: 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. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86.
Все срабатывает нормально: 2289 записей было обновлено в таблице EXTDOSES 2072 записей было обновлено в таблице DOSES 217 записей было добавлено в таблицу DOSES То же самое с теми же данными (Restore из того же Backup) делаю в FB 4.0 Beta1 Release и получаю: 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 "UNQ_DOSES" on table "DOSES". Problematic key value is ("DOSETYPE_ID" = 18, "PERSONNEL_ID" = 2853, "YEAR_REP" = 2018, "DOSETERM_ID" = 4). At block line: 55, col: 7. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2019, 16:11 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
dedRasta, update/insert из for select без plan sort на 2.5 если и работал, то случайно - внешний for select мог увидеть вставляемые или обновляемые записи. в 4.0 - не видит. используй https://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-dml-merge.html ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2019, 16:45 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
Вспомнил, эта тема здесь обсуждалась и тогда говорилось, что в дальнейшем это поведение будет пресечено. Переделал с использованием MERGE: Код: 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. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56.
Выполняю, получаю: 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 "UNQ_DOSES" on table "DOSES". Problematic key value is ("DOSETYPE_ID" = 18, "PERSONNEL_ID" = 2853, "YEAR_REP" = 2018, "DOSETERM_ID" = 4). Получается, что MERGE не видит вновь введенных записей при проверке MATCHING, пытается сделать INSERT вместо UPDATE и обламывается. В доке написано: Если условие WHEN MATCHED присутствует, и несколько записей совпадают с записями в целевой таблице, UPDATE выполнится для всех совпадающих записей источника, и каждое последующее обновление перезапишет предыдущее. Это нестандартное поведение: стандарт SQL-2003 требует, чтобы в этой ситуации выдавалось исключение (ошибка). В принципе мне именно это и нужно (кумулятивное суммирование в найденные записи), но раз нельзя, значит нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 11:03 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
dedRasta, эээ, то есть, исходная идея, и работает на 2.5, чтобы если записи нет, она была вставлена, а ПОТОМ еще и ОБНОВЛЕНА? Типа, увидит-не-увидит? Что это за ... алгоритм такой? dedRastaПолучается, что MERGE не видит вновь введенных записей при проверке MATCHING да почему он их должен увидеть? Если надо сначала вставить записи, которых нет, а потом обновить, то так и надо делать, в два этапа. А не ориентироваться на то, что в 2.5 курсор видит вставляемые записи. Закладываться на конкретную реализацию, которая еще и "нестабильна" - это пипец. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 12:39 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
dedRastaВ доке написано: Если условие WHEN MATCHED присутствует, и несколько записей совпадают с записями в целевой таблице, UPDATE выполнится для всех совпадающих записей источника, и каждое последующее обновление перезапишет предыдущее. Это нестандартное поведение: стандарт SQL-2003 требует, чтобы в этой ситуации выдавалось исключение (ошибка). В принципе мне именно это и нужно (кумулятивное суммирование в найденные записи), но раз нельзя, значит нельзя. это примечание касается многократного UPDATE, когда запись была в целевой таблице изначально. Впрочем даже эта часть будет выполнена не верно ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 12:45 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
dedRastaВ принципе мне именно это и нужно (кумулятивное суммирование в найденные записи), но раз нельзя, значит нельзя. это вы так думаете. На самом деле суммы можно посчитать ещё в USING, сделав таким образом однократный INSERT или UPDATE ровно одной записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 12:49 |
|
FB4: violation of PRIMARY or UNIQUE KEY constraint
|
|||
---|---|---|---|
#18+
ГринГоп вызвал его в каюту и, раскрыв истрепанную книгу, сказал: —Слушай внимательно! Брось курить! Начинается отделка щенка под капитана. И он стал читать, — вернее, говорить и кричать, по книге, древние слова моря. Спасибо! Теперь работает и в FB4 и в FB25: Код: 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. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2019, 09:52 |
|
|
start [/forum/topic.php?fid=40&fpage=25&tid=1560774]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 161ms |
0 / 0 |