Вобщем, если создать наново базу, то все нормально.
А вот если перенести базу с 2.0 на 2.1, бекап на 2.0,
рестор на 2.1, то в процедурах с кириллицей вообще получим
(Blob read error:
can't format message 13:686 -- message system code -4.
Cannot transliterate character between character sets.
)
И еще, можно теперь создавать процедуры/домены/таблицы рідною мовою,
но вот план тогда показывается уникодный, а значит кракозябрами. Кто в
этом случае виноват?
Андрій Жук wrote:
И еще, можно теперь создавать процедуры/домены/таблицы рідною мовою,
но вот план тогда показывается уникодный, а значит кракозябрами. Кто в
этом случае виноват?
База должна быть в ODS11.1. В этом случае у меня в IBE план в cp1251
показывается (как и должно быть).
--
Андрій Жук wrote:
Вобщем, если создать наново базу, то все нормально.
А вот если перенести базу с 2.0 на 2.1, бекап на 2.0,
рестор на 2.1, то в процедурах с кириллицей вообще получим
(Blob read error:
can't format message 13:686 -- message system code -4.
Cannot transliterate character
DY Это предсказуемо, но не лечится в принципе.
это конечно совсем даже не хорошо.
Большой разрыв между 2.0 и 2.1
уже одну и туже базу нельзя будет использовать на 2.0 и 2.1,
для сисадминов будет большой головняк при апгрейде.
DY Придется тем или иным способом перекодировать уже существующие
DY
Alexandr Kochmin wrote:
это конечно совсем даже не хорошо.
Согласен. Но лучше варианта пока не нашли. Очень тяжело искоренять
старую кривизну без последствий, увы.
Большой разрыв между 2.0 и 2.1
уже одну и туже базу нельзя будет использовать на 2.0 и 2.1,
Это никогда не
DY Придется тем или иным способом перекодировать уже существующие
DY метаданные после рестора.
а как?
Я начинаю думать, чтоб избавиться вообще от русских букв в тексте SP тем
или иным способом.
выгрузка в скрипт и обратно. текстовые файлики рулят :)
--
Булычев Алексей
Hi Alexandr Kochmin !
AK Я начинаю думать, чтоб избавиться вообще от русских букв
AK в тексте SP тем или иным способом.
:)
читаем тут: http://www.ibase.ru/devinfo/ibrusfaq.htm
Русские буквы в хранимых процедурах, триггерах и exceptions ну и так далее.
--
Я для себя простенький скрипт написал по апдейту блобов. Можно включить
нечто подобное в дистрибутив.
Дима, а почему не сделать чтобы рестор 2.1, видя что в базе системные
объекты (процы, триггеры) не в уникоде, автоматом перекодировать их в
уникод?
Oleg Matveyev wrote:
вот если бы ключик в gfix -а на самом деле кодировка там WIN1251
или прямо при Restore ключ такой
Ключик для конкретной версии сервера?
--
Дмитрий Еманов
Ключик для конкретной версии сервера?
Да, а почему нет?
Т.е. мы имеем проблему с переходом с баз пре2.1 на пост2.1.
Вводим в жфикс спец ключ, типа -convert_blobs_of_sys_objects
-codepage_that_is_in_the_database win1251
в сад, да?
Я для себя простенький скрипт написал по апдейту блобов. Можно включить
нечто подобное в дистрибутив.
Дима, а почему не сделать чтобы рестор 2.1, видя что в базе системные
объекты (процы, триггеры) не в уникоде, автоматом перекодировать их в
уникод?
нужно же откуда-то знать, какая там
Plotnikov Y wrote:
Дима, а почему не сделать чтобы рестор 2.1, видя что в базе системные
объекты (процы, триггеры) не в уникоде, автоматом перекодировать их в
уникод?
А откуда он узнает, в какой кодировке они лежат? Это только ты знаешь,
что подключался всю жизнь с cp1251...
--
Дмитрий
Plotnikov Y wrote:
Вводим в жфикс спец ключ, типа -convert_blobs_of_sys_objects
-codepage_that_is_in_the_database win1251
в сад, да?
Пока еще нет :-) Почему оный ключик должен быть в gfix, а не в gbak?
Ведь операция разовая и касается только апгрейда...
--
Дмитрий Еманов
Почему оный ключик должен быть в gfix, а не в gbak?
ну я сначала Юре предложил именно в gbak,
но вместе решили что вообще -то BLR при восстановлении не трогается
Oleg Matveyev wrote:
но вместе решили что вообще -то BLR при восстановлении не трогается
А причем тут BLR? Речь ведь про SOURCE/DESCRIPTION.
Или типа раз рестор и раньше сам ничего в данных не трогал, то и нефиг ему?
--
Дмитрий Еманов
Или типа раз рестор и раньше сам ничего в данных не трогал, то и нефиг
ему?
ну как бы - да.
Хотя конечно, так неудобно...
Я всегда мигрировал со старой версию в новую используя только gbak.
но вспомните переход на третий диалект например.
и что? никто не умер.
хотя некоторые так и сидят на
Тут, имхо, вообще вопрос философский. В смысле - как удобнее или как
логичнее.
почему допустим логично жфикс. Жфикс предназначен для хирургического
ковыряния скальпелем в живой базе данных. Ну, или неживой, это уже как
повезет, не суть. А жбак - вроде как штатное средство, которое имеет
Alexandr Kochmin ...
DY Это предсказуемо, но не лечится в принципе.
это конечно совсем даже не хорошо.
Большой разрыв между 2.0 и 2.1
уже одну и туже базу нельзя будет использовать на 2.0 и 2.1,
для сисадминов будет большой головняк при апгрейде.
Отставить панику ;) Придумаем
VH
VH Отставить панику ;) Придумаем чего-нить
да да. был бы очень рад. А то сейчас как-то грустно.
--
С уважением
Кочмин Александр
Firebird Foundation associate member #257
20 matches
Mail list logo
