|
Database Comparer
|
|||
---|---|---|---|
#18+
В БД есть 2 таблицы. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
По полю T2.FID наложен FK на таблицу T1.ID Есть копия БД, в которой отличается имя PK таблицы T1 (в другой БД он называется PK_T1): Код: plsql 1.
Database Comparer выдает скрипт: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Но удалить PK для его пересоздания нельзя, пока есть FK. С уважением, Polesov. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 13:31 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
В догонку: - версия IBE 2016.8.9.1 - отличается имя индекса PK ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2016, 13:34 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Polesov- отличается имя индекса PK Уточни: имя ограничения в обеих базах одно и то же? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2016, 07:02 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
IBExpert, Отличается имя PK для T1, имя FK в обеих БД одинаково. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2016, 12:04 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
IBExpertPolesov- отличается имя индекса PK Уточни: имя ограничения в обеих базах одно и то же? в нашем реальном примере отличалось имя ИНДЕКСА первичного ключа, а имя САМОГО пк совпадало. А в показанном выше тестовом примере так: в базе1: ALTER TABLE T1 ADD CONSTRAINT PK_T1 PRIMARY KEY (ID); в базе2: ALTER TABLE T1 ADD CONSTRAINT PK_T10 PRIMARY KEY (ID); всё остальное совпадает. и в том и в другом случае компарер не генерит никаких действий с FK_T2_1. Кстати, в версии 2014 года всё работает правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2016, 12:23 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Добрый день. В 2-х одинаковых БД есть таблица: Код: plsql 1. 2. 3. 4. 5.
В БД 1 меняем вычисляемое поле: Код: plsql 1.
и порядок полей: Код: plsql 1.
В БД 2 делаем зависимость в процедуре на вычисляемое поле: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Компарер выдает такой скрипт: Код: plsql 1. 2. 3. 4. 5.
Во 2-й БД не учитывается зависимость поля C_VAL - первая строка скрипта вызовет ошибку. С уважением, Polesov. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2016, 18:59 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Добавлю. В немного другой ситуации в этом примере, когда зависимости нет, и порядок полей в обеих базах одинаков, при изменении вычисляемого поля, идущего вторым и зависящего от третьего, оно пересоздаётся и становится третьим, т.е. порядок не меняется. в настройках флаг "Ignore Column Position" снят. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2016, 19:16 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Ещё две проблемы в одном примере: Проблема 1: База DB1: Код: sql 1. 2.
Код: sql 1. 2. 3. 4. 5. 6. 7.
База DB2: Код: sql 1. 2.
Код: sql 1. 2. 3. 4. 5. 6. 7.
Сравниваем компарером D1 => D2 и получаем: Код: sql 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.
что выдаёт ошибку. Нужно поменять местами удаление домена и изменение процедуры в которой он перестал использоваться. Проблема 2: комментарии к параметру процедуры. Если в конце к "нормальному" тексту комментария в одной из баз добавлены нулевые символы, то, во-первых, компарер видит, что комментарии различны (и это, в принципе, правильно), и во-вторых, теряется закрывающий апостроф! (Каким образом нулевые символы получаются в комментариях к параметрам - это уже другой вопрос IDExpert-а, не относящийся к компареру.) DB1: Код: sql 1. 2. 3.
DB2: Код: sql 1. 2. 3.
получаем такой скрипт, где пропущен закрывающий апостроф: Код: sql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2016, 10:59 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
max_2015получаем такой скрипт, где пропущен закрывающий апостроф: Нулевой символ в тексте трактуется редактором как конец всему и вообще, за ним жизни нет. Как нулевые символы в комментарии попадают - это не к эксперту вопрос. Остальное еще не смотрел. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2016, 15:46 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
IBExpertНулевой символ в тексте трактуется редактором как конец всему и вообще, за ним жизни нет. Как нулевые символы в комментарии попадают - это не к эксперту вопрос. Но точку с запятой он после этой незакрытой апострофом строки ставит. Т.е. дело не в редакторе, в котором просматривается скрипт, а в формировании строки. Предлагаю вставить удаление нулевых символов из комментариев, если они встречаются. А откуда они берутся, мы ещё не разобрались. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2016, 11:14 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
IBExpert, Зашёл в проблемную процедуру, ситуация следующая: У нескольких параметров есть комментарии, все они содержат нули в конце. В "Ленивом режиме" они все видны, а если перейти на вкладку "скрипт", то там внизу отображается только первый комментарий без закрывающего апострофа и всё. Т.е. тут - да, для редактора конец всему... Потом вручную в RDB$PROCEDURE_PARAMETERS поменял первый комментарий, убрав нули. В процедуре во вкладке "скрипт" первый комментарий стал отображаться корректно, за ним второй без закрывающего апострофа и всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2016, 12:29 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Снова сравнение базы. Ошибка проявляется только при сравнение с файлом sql master.sql Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
slave.sql Код: sql 1. 2. 3. 4.
результат Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
ошибка в Код: sql 1.
т.е. нет типа integer ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2016, 17:13 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
PolesovВо 2-й БД не учитывается зависимость поля C_VAL - первая строка скрипта вызовет ошибку. Во-первых, какая версия эксперта? Во-вторых, сравниваются БД или скрипты или БД со скриптами? В-третьих, нельзя ли целиком скрипты для тест-кейзов предоставлять, чтобы я не парился? Я попытался воспроизвести проблему по описанию: Код: sql 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.
Компарер выдал следующий скрипт (образцовая - вторая БД): Код: sql 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.
И после выполнения этого скрипта компарер, естественно, различий не находит. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2016, 04:33 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
max_2015что выдаёт ошибку. Нужно поменять местами удаление домена и изменение процедуры в которой он перестал использоваться. Это исправил. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2016, 05:23 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
max_2015Предлагаю вставить удаление нулевых символов из комментариев, если они встречаются. Ну, нет. Не буду я этим заниматься, наверное. Это надо в сотне мест, где RDB$DESCRIPTION читается, соответствующие правки делать, это раз. Почему удалять, а не на пробелы, например, заменять? Это два. Если в базе есть нули в комментах - они всплывут где-нибудь еще, не обязательно в эксперте. Это три. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2016, 05:30 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
noisy_byт.е. нет типа integer Исправил. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 08:24 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Наконец-то :) Хоть ещё кто-то напоролся - не только я. Баян же аж июньский! http://www.sql.ru/forum/1220154/databasecomparer-dayot-raznye-rezultaty-sravneniya Ща опробируем в бою! P.S. Отлично. Теперь всё без ошибок! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 10:00 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
P.P.S. Авотфиг! Проблема остается, если поля таблицы описаны не типами, а доменами! Ща подготовлю набор для теста. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 10:13 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
База из 1 домена, 1 таблицы с 1 полем и 1 селективной процедурой 1) Создайте базу из этого скрипта. Код: 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. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99.
2) Скрипт другой базы. Та же 1 таблица, но полей в ней уже 2 и та же 1 селективная процедура, но с 2 параметрами. Код: 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. 87. 88. 89. 90. 91.
Базу со второго скрипта создавать не надо. Запускаем сравнение баз. И сравниваем источник-скрипт 2 с базой назначения 1. Получаем неверный разностный скрипт с ALTER PROCEDURE T1_SEL RETURNS ( --НЕТ ТИПА ПАРАМЕТРОВ F1 /* TYPE OF COLUMN T1.F1 */ , F2 /* TYPE OF COLUMN T1.F2 */ ) AS BEGIN SUSPEND; END ^ Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 10:31 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
o_v_aЩа опробируем в бою! P.S. Отлично. Теперь всё без ошибок! Ничоси! А ведь даже еще не выкладывал пофиксенную версию... А оно само! Ничоси! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 12:30 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
Ну вот с доменами пофиксишь - будет "ничоси"! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 13:57 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
o_v_aЩа опробируем в бою! Вот сейчас можно воевать. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 16:14 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
СПАСИБО!!! Проверил - всё хорошо! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 16:39 |
|
Database Comparer
|
|||
---|---|---|---|
#18+
PolesovДобрый день. В 2-х одинаковых БД есть таблица: Код: plsql 1. 2. 3. 4. 5.
В БД 1 меняем вычисляемое поле: Код: plsql 1.
и порядок полей: Код: plsql 1.
В БД 2 делаем зависимость в процедуре на вычисляемое поле: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Компарер выдает такой скрипт: Код: plsql 1. 2. 3. 4. 5.
Во 2-й БД не учитывается зависимость поля C_VAL - первая строка скрипта вызовет ошибку. С уважением, Polesov. тут забыли указать самую важную вещь: в Options флаг "Procedures" снят! Именно тогда такое происходит. Но этот флаг должен по идее обозначать то, что не нужно менять отличающиеся процедуры. Но в данном случае процедура не отличается, а её временное изменение и потом обратно требуется в технических целях (по сути, внутренние цели компарера, не влияющие на конечный результат для пользователя), поэтому технические действия с процедурой должны выполняться в любом случае. Версия Firebird - 2.5.6 Версия IBExpert - 2016.8.9.1 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 16:26 |
|
|
start [/forum/topic.php?fid=42&msg=39298306&tid=1599229]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 289ms |
total: | 430ms |
0 / 0 |