Interbase SMP 2009 в Windows Server 2019 ошибка сохранения EXCEPTIONS

Доброго дня!

При переносе базы interbase 2009 со старой тачки на новую с новой Windows Server 2019 возникла следующая проблема.
Перестали в клиенте программы, написанной еще в D7, появляться exceptions от БД из хранимок.
Начал смотреть, разбираться, решил перекомпилировать хранимку, которая должна отдавать текст warning от exceptions и обнаружил, что при компиляции хранимки получаю ошибку, мол "arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets.".
Долго не мог понять, где вдруг появились кодировки, которые не может компилятор обработать. Методом исключения нашел, что такие места вызывают куски кода, где происходит проверка условия и по нему выкидывается exceptions на клиент. Попробовал отредактировать текст самого exceptions и в ответ получил вот такое:
"This operation is not defined for system tables.
unsuccessful metadata update.
MODIFY EXCEPTION failed.
arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets."

Причем под более старой версии Windows 7 х64 или Windows Server 2008 х64 такой проблемы само собой не наблюдалось. Понимаю, что большая разница в версиях системы и могли появиться более весомые изменения в системной кодировке по умолчанию или иных настройках. Плюс версия самой базы уже старенькая. Но кодировка, где хранятся сообщения, имеет значение "None", как и collate. Даже не unicode_fss, как большинство остальных полей в системных таблица. Пробовал менять кодировку и collate у этого поля в таблице rdb$exceptions. Не помогло.

Может кто-то сталкивался с подобным и сможет подсказать как это решить?
Или тут уже ничего не поделать и пора переходить на более новую версию Interbase? 2020 к примеру.

0

Сообщение от mad_smoker82 пора переходить на более новую версию Interbase?

Однозначно пора. Вот только почему IB? А почему не Firebird?

1

А какая вообще кодовая страница для строковых данных?

Добавлено через 4 минуты
Пардон, невнимательно читал. Кодировку none придется переделывать. И это отдельная задача.
Новые версии сервера тут вряд ли помогут.
Берешь бэкап gbk и восстанавливаешь с изменением кодировки. Но это отдельная тема. В интернете полно рекомендаций,
но базы у всех разные.

1

Сообщение от D1973 Однозначно пора. Вот только почему IB? А почему не Firebird?

Потому что система разрабатывалась с начала 2000-х и ib был выбран, как наиболее подходящий. Потом, как мне рассказывали, были попытки перенести это на fb, когда тот появился. Но на тот момент он был еще в зачаточном состоянии и не обеспечивал всех потребностей) По причине отсутствия у MySQL хранимок на нее так же не был совершен порт в другое время. А сейчас вроде и fb хорош, и ib подтянулся с новыми версиями, и MySQL может хранимки, но порт затребует времени массу. Таблиц не так много 130-150, хранимок >1500, объем базы почти 22 гига. Плюс система на delphi 7 в несколько десяток или сот тысяч строк кода. Поэтому порт могу сделать, но постоянно возникающие задачи по дальнейшему развитию этой системы не дадут это сделать достаточно быстро))) там по сути за все эти годы выросла своя CRM завязанная с кучей других систем в месте, где я работаю)

Добавлено через 3 минуты

Сообщение от DedFriend Пардон, невнимательно читал. Кодировку none придется переделывать. И это отдельная задача. Новые версии сервера тут вряд ли помогут. Берешь бэкап gbk и восстанавливаешь с изменением кодировки. Но это отдельная тема. В интернете полно рекомендаций, но базы у всех разные.

Да, там же у системных таблиц свои причуды) В частности имя exception в unicode_fss, а сам текст без определенной кодировки. То есть пиши на чем хочу, а клиентская часть потом сама разберется. Либо при этом текст пытается перекодироваться в кодировку той системы, где все это счастье лежит.

То есть даже так. Ну перенос-то я и делал через backup/restore. Значит нужен будет повторный restore, только с изменением кодировки. Спасибо, попробую поискать в нете инфо в этом ключе.

0

Заметил еще странности с этой базой.
Есть системная таблица rdb$database, где в поле RDB$CHARACTER_SET_NAME по идее указана кодировка, которая была выбрана при создании базы. Я пару баз создал тестовых, указав в первый раз кодировку NONE, во второй WIN1251. В этих базах в этой системной таблице в этом поле были соответствующие значения. Причем в системных таблицах RDB$ некоторые поля таки имеют по умолчанию кодировку NONE, т.е. это не зависит от выбранной кодировки при создании.
Однако, когда посмотрел rdb$database у рабочей базы, то в поле RDB$CHARACTER_SET_NAME просто было NULL. Что меня озадачило сильнее))))
У пользовательских таблиц в базе кодировка при создании указывалась WIN1251 и у полей varchar тоже. Поэтому там-то вопросов нет.
Просто получается, а где именно кодировку менять то надо? То что у самой базы там стоит null это треш конечно. У системных таблиц для полей varchar кодировка NONE это похоже норма. Хотя после других баз с которыми работал, это странно конечно.

В моем случае наверно только, если попробовать создать новую базу с корректным выбором кодировки WIN1251, после извлечь метадата из рабочей и поместить в новую. А потом уже и данные перенести из рабочей в новую. И после проверить будет ли появляться ошибка при попытке отредактировать exception и соответственно будет ли ошибка при попытке скомпилировать процедуру из-за таких exception под windows 10/windows server 2019. Потому что под версиями ниже такой ошибки я не наблюдал.

0

Извиняюсь, надо было сразу приложить скрины.
Собственно вот, что я вижу, когда пытаюсь сохранить exception.


Та же самая ошибка появляется, когда пытаюсь скомпилировать процедуру, в которой есть условие с exception.

Комментирую кусок с exception и компиляция проходит нормально.

Собственно вот поле character set из системной таблицы rdb$database


А вот структура системной таблицы exception.


Ровно точно такая же структура у этой таблицы, когда создается база с нормальным указанием кодировки по умолчанию.
Дело возможно конечно не в этом, а не дает сохранить возможно по другой причине.

0

Вручную менять значения полей у системных таблиц - гнилое занятие. Я когда-то тоже пробовал, но ничего хорошего не получилось

0

Сообщение от DedFriend Вручную менять значения полей у системных таблиц - гнилое занятие. Я когда-то тоже пробовал, но ничего хорошего не получилось

Я вручную даже непытаюсь сменить кодировку в rdb$database)
Да и копание в системных таблицах дело интересное, но лучше в плане изучения конечно.
Хотя иногда и бью себя по рукам за то, что скопировать права с одного пользователя на другого гораздо быстрее через RDB$USER_PRIVILEGES в один запрос, чем лопатить портянки с разрешениями на все соответствующие таблицы и процедуры. Тем более, когда у тебя "над душой" стоят и ждут, что ты сделаешь это в мгновение ока)

А exception редактируется из соответствующего раздела в ibexpert

0

Создавал чистую базу с корректным указанием кодировки базы. Excpetions на русском просто не воспринимает. Ни создание, ни редактирование.
Обновил interbase до версии 2020 и проблема ушла.
Правда подраспухла база немного при развертывании из бэкапа, но зато теперь ошибок нет.
Тестирую работу старой программы с новой версией IB и замечаю, что все стало шевелиться гораздо быстрее.

В принципе вопрос можно считать закрытым тогда)

0