Support Forum

[ova]

Похожие темы есть. Некропостингом заниматься не стал. Немного не тот случай. Это скорее отчет о проделанной работе.
Я тестировал с момента первичного знакомства систему на локальной машине под WinXP. База на Firebird SQL 1.5.x. Поддержки UTF-8 в Firebird 1.5.x нет, поэтому база создавалась с кодировкой по умолчанию NONE.
Соответственно, пока в локале игрался, то все писалось в базу в кодировке WIN1251 - в кодировке виндовой локали.
Решил перенести систему на тестовый сервер под Linux. Локаль там, естественно, вовсе не WIN1251, а UTF-8. От того все кириллические данные из базы после переноса TS с винды на линукс "в лоб прямым копированием и последующим редактированием необходимых properties" стали показываться ромбиками-вопросиками, ибо встроенного прекодирования от SQL-сервера к клиенту при передаче строковых данных нету, оно только в Firebird 2.0 появилось, да и не могло быть на базе с кодировкой NONE по умолчанию).
Решение на поверхности, как ни странно, помогло: метаданные и данные из базы слить в скрипт, сохранить скрипт в кодировке UTF-8 и выполнить этот скрипт на linux-сервере, создав таким образом новую базу, данные в которой автоматически получаются уже в кодировке UTF-8.
ПО-МО-ГЛО!!!
Т.е. данный пост еще раз в подтверждение того, что кодировки приложений, java и данных в базе должны сов-па-дать!
-------
И еще: у меня нет графического интерфейса на сервере (нафиг не нужен был всегда, это моя религия - не обсуждается). При создании скрипта (если кто желает) для автозапуска jetty через /etc/init.d прежде, чем стартовать jetty не забывать
LANG=ru_RU.UTF-8 прописать. Не знаю как с остальными дистрибутивами, но в OpenSUSE обязательно. Иначе скрипт /sbin/service делает в начале своей работы LANG=POSIX и усё, приплыли: при использовании старта через этот скрипт в виде
service trackstudio start
получаем неверную кодировку.

[PoleSoft]

Эта проблема не только при переходе с Win на Lin. У нас на Linux-сервере стоит локаль в KOI8-R и, соответственно, в базе Firebird (с кодировкой NONE) теперь все символы в ней. Приходиться ставить персонально локаль для TS (потому что он системную не использует?) в /etc/rc.d/trackstudio. И если забыть это сделать, то как минимум в базе поломаются имена вошедших пользователей (Петров А станет ?????? ?). Выглядит как косяк TS... Все данные светятся ромбиками и кракозябрами и если что-то ввести, то это сохраниться в базу в кодировке UTF-8 (это объяснимо и понятно). А вот имя пользователя зачем сохранять (и ломать), если он только вошел и вышел (понятно, что сохраняется время входа в USER_LASTLOGON, но зачем USER_NAME в UPDATE включать?).
Имхо, а делать базу в UTF-8 (если нет разнонеанглоязыких пользователей) неразумно... это несколько замедлит работу с ней из-за увеличения длины строк.

[ova]

Эта проблема не только при переходе с Win на Lin. У нас на Linux-сервере стоит локаль в KOI8-R и, соответственно, в базе Firebird (с кодировкой NONE) теперь все символы в ней. Приходиться ставить персонально локаль для TS (потому что он системную не использует?) в /etc/rc.d/trackstudio.

Вот. Вся фишка и состоит в том, что кодировка данных в базе должна совпадать с локалью, с которой работает TS. Подозреваю, что и у тебя системные скрипты меняют LANG= на не то, что надо. Поэтому требуется подтачивать /etc/rc.d/trackstudio. Кстати, я скрипт тоже не мудрствуя лукаво так же назвал - trackstudio

[admin]

Эта проблема не только при переходе с Win на Lin. У нас на Linux-сервере стоит локаль в KOI8-R и, соответственно, в базе Firebird (с кодировкой NONE) теперь все символы в ней. Приходиться ставить персонально локаль для TS (потому что он системную не использует?) в /etc/rc.d/trackstudio. И если забыть это сделать, то как минимум в базе поломаются имена вошедших пользователей (Петров А станет ?????? ?). Выглядит как косяк TS... Все данные светятся ромбиками и кракозябрами и если что-то ввести, то это сохраниться в базу в кодировке UTF-8 (это объяснимо и понятно). А вот имя пользователя зачем сохранять (и ломать), если он только вошел и вышел (понятно, что сохраняется время входа в USER_LASTLOGON, но зачем USER_NAME в UPDATE включать?).
Имхо, а делать базу в UTF-8 (если нет разнонеанглоязыких пользователей) неразумно... это несколько замедлит работу с ней из-за увеличения длины строк.

TS системную кодировку в самом деле не использует, т.к. база чаще всего в UTF-8, а системная может быть какой угодно.
По поводу сохранения пользователей - это Hibernate сам решает как обновлять, мы генерируемый им SQL не контролируем.

[PoleSoft]

Ну... озадачен... Hibernate не знаю, изучать времени нет. Либо он тупой, либо не так используется. Зачем обновлять поле, которое не менялось? Может, кто раскроет мне глаза пошире? Понятно, что проблема точечная, но если ВСЁ так работает, то это совсем не гуд. Уже были случаи, что форма редактирования не до конца прорисовывалась в браузере (некоторые поля отсутствовали вообще в таблице) и при нажатии Сохранить значения этих полей сносились напрочь. Понятно, что если обновлять ВСЕ поля, то в базу уйдет NULL.

[admin]

Ну... озадачен... Hibernate не знаю, изучать времени нет. Либо он тупой, либо не так используется. Зачем обновлять поле, которое не менялось? Может, кто раскроет мне глаза пошире? Понятно, что проблема точечная, но если ВСЁ так работает, то это совсем не гуд. Уже были случаи, что форма редактирования не до конца прорисовывалась в браузере (некоторые поля отсутствовали вообще в таблице) и при нажатии Сохранить значения этих полей сносились напрочь. Понятно, что если обновлять ВСЕ поля, то в базу уйдет NULL.

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

Мы же не знаем, какие поля пользователь редактировал - если в форме часть полей пустые (потому что там что-то недогрузилось, из-за глюка или потому что пользователь их очистил), то никаких других вариантов, кроме как записать все в базу у нас нет.

[PoleSoft]

Как это не знаете? Перед началом редактирования значения сохраняются, потом перед сохранением сравниваются и собирается четкий update только измененных полей, но это руками делать естественно напряжно, если движок сам это не умеет. Ввод в базу через веб - это, к сожалению, неизбежное зло .

[ova]

Немного дополню по горячим следам, пока не забыл.
После очередного обновления сервера перестала нормально подхватываться кириллица.
Глянул в скрипт и нифига не понял, как же это работало раньше.
В скрипте запуска /etc/init.d/trackstudio вместо
LANG=ru_RU.UTF-8
написал
export LANG=ru_RU.UTF-8
и все нормализовалось.
Собственно, скрипт работы при загрузке OpenSUSE у меня сейчас такой:
#!/bin/bash
# /etc/init.d/trackstudio
#
progdir="/opt/TS4012"
prog="./startJetty"
progOFF="./stopJetty"

export LANG=ru_RU.UTF-8

start(){
#-----------------------------------------------------------
echo -n $"Starting $prog: "
cd $progdir
sudo "$prog"&
#-----------------------------------------------------------
}
stop(){
echo -n $"Stopping jetty: "
cd $progdir
sudo $progOFF
# rc_status -v
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo $"Usage: $0 {start|stop|restart}"
esac
#
#
--
C уважением,
Василий
P.S. TS обновить бы пора, но руки не доходят

[ova]

А вот опять проблема... Не спасло.
Возникла необходимость перезагрузки сервера в ночное время. Обратил внимание, что утром (после ночной перезагрузки ) TS некорректно работает - login спрашивает по-английски а не по-русски и в дальнейшем вообще нормально не функционирует, сыпля ошибками. В местах, где нет стек-трейсов ошибок, на экране сплошные ????????.
Т.е. на лицо проблема несовпадения кодировки локали с кодировкой базы.
Захожу в консоль сам (с локалью UTF-8, естественно), делаю перезапуск службы
service trackstudio restart
Все нормализуется.
А вот при загрузке во время запуска системы - ну хоть застрелись - не подхватывается локаль UTF-8 и все тут.
OpenSUSE 11, cкрипт /etc/init.d/trackstudio в предыдущем посте. Прописан для выполнения на 3 и 5 уровнях запуска.
Установил TS 4.0.14/ . Буду наблюдать. Но мне кажется, что не в версии TS дело...
Как пойму, в чем не прав, обязательно отпишусь.