|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
Симонов Денис да не, при включённых настройках совместимости всё будет работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2020, 12:47 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
Симонов ДенисКак по мне, то в современных условиях нужны только две кодировки UTF-8 и OCTETS для бинарных данных. Причём вторая тоже сомнительна из-за появления (VAR)BINARY, который может поменять свою внутреннюю сущность. Это сейчас он просто хак из-за того, что половина движка во имя взадсовместимости не поддерживает подтипы для строковых полей. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2020, 13:06 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
Всем привет. К сожалению, на форуме нельзя прикрепрять файлы более 150килобайт. В линке база с непонятными артефактами . В ней есть проекция VW_ARTIKEL_PG. Если ее фетчить до конца, то выкинется Arithmetic exception. Связанные с ней таблицы фенчатся нормально. Если ее удалить и создать заново, то ошибка исчезает. Вопрос, что могло привести к подобным дефектам? И это единичный случай (Именно на этой проекции). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2020, 13:51 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
svdчто могло привести к подобным дефектам? Использование литералов в тексте представления. Изменение структуры таблиц на которых она построена. Нет, баз я не качал и не открывал. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2020, 13:58 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
Всем привет. повторилась ошибка с греческой буквой µ. База данных лежит тут. В таблице ARTIKEL имеет следующую структуру: Код: 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.
отображает все без проблем для записи с ARTIKELCODE=5012616173004 (первая запись, если сортировать по имени). Таблица используется в проеции VW_ARTIKEL_PGЮ Код: 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.
Если фетчить проецию VW_ARTIKEL_PG, то выкидывает ошибку, хотя таблица отображается без каких либо проблем: cannot transliterate character between character set: Код: plsql 1. 2. 3.
Firebird 2.5.9.27139 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 11:03 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
svd, Вот это тоже фетчится без проблем ? Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 11:41 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
hvlad, да, запрос отобрадает без проблем. Прямо в первой позиции находится проблемная запись без каких либо Arithmetics exception. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 12:16 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
svd, а если чарсет коннекта не utf8, а ISO8859_1 ? Насколько я вижу, в полях GName и Name последняя буква (греческое мю ?) не является буквой кодировки ISO8859_1, отсюда проблема транслитерации. VW_ARTIKEL_PG была создана в коннекте с чарсетом ISO8859_1 и поэтому содержит строковые литералы в этом чарсете. Вот соотв. часть BLR (21 - это charset id для ISO8859_1): Код: plaintext 1. 2. 3.
Когда COLEASECE сравнивает GName (UTF8) с пустой строкой в ISO8859_1 - оно приводит GName к ISO8859_1 и получает ошибку транслитерации. Не буду сейчас выяснять, к какому чарсету нужно было кого приводить, но сейчас оно вот так работает. Чтобы это исправить, достаточно пересоздать VW_ARTIKEL_PG в коннекте с чарсетом UTF8. Или явно указывать чарсет литералов (_utf8 ''), но это нехорошо выглядит, как по мне. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 13:11 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
13.04.2021 13:11, hvlad пишет: > Или явно указывать чарсет литералов (_utf8 ''), но это нехорошо выглядит, как по мне. вполне нормально оно выглядит. мы для литералов пользуем _win1251. и не нужно перекодировать метаданные при миграции. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 13:21 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
hvlad, Спасибо большое. Это вносит некоторое понимание, почему после перекомпиляции вдруг начинает работать. Хотя нужно проверить всю цепочку наших апдейтов - в один момент происходит удаление всех триггеров, проекций и процедур и потом восстановление удаленных из скрипта. Вероятно там как раз соединение идет по ISO8859, а не по UTF8. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 14:43 |
|
FB 2.5.5 проблема со столбцами UTF8
|
|||
---|---|---|---|
#18+
svd, непонятно, зачем в таблице половина строк без кодировки (или с дефолтной кодировкой БД), и половина - с UTF8. Такое впечатление, что нечем развлечься. :-) Если делается перевод на utf8, то переводить надо все метаданные. p.s. про приколы типа DELETEFLAG VARCHAR(1) я уж вообще молчу. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2021, 15:23 |
|
|
start [/forum/topic.php?fid=40&gotonew=1&tid=1560059]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
138ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 235ms |
total: | 490ms |
0 / 0 |