DBEdit отображает только половину русских символов
Модератор: Модераторы
DBEdit отображает только половину русских символов
Lazarus 1.0.6, FPC 2.6.0, Windows 7 32 bit
Ситуация такая: есть база данных на Firebird 2.5 на UTF-8. Есть в ней таблица и поле типа varchar(4). Если пользоваться FlameRobin (утилита для редактирования БД), то все нормально - в это поле прекрасно вводятся строки типа '1234', 'abcd' и 'абвг'. Но когда с этим полем начинаешь работать в Lazarus'е, начинаются чудеса: помещаем на форму DBEdit, связанный с этим полем. В него можно спокойно ввести строки типа '1234' и 'abcd', но вот 'абвг' вводится только наполовину, т.е. как 'аб'. Если насильно ввести 'абвг' с помощью FlameRobin, то в DBEdit оно отображено будет все равно только как 'аб'.
Уважаемые форумчане, что это такое и как с этим бороться?
Ситуация такая: есть база данных на Firebird 2.5 на UTF-8. Есть в ней таблица и поле типа varchar(4). Если пользоваться FlameRobin (утилита для редактирования БД), то все нормально - в это поле прекрасно вводятся строки типа '1234', 'abcd' и 'абвг'. Но когда с этим полем начинаешь работать в Lazarus'е, начинаются чудеса: помещаем на форму DBEdit, связанный с этим полем. В него можно спокойно ввести строки типа '1234' и 'abcd', но вот 'абвг' вводится только наполовину, т.е. как 'аб'. Если насильно ввести 'абвг' с помощью FlameRobin, то в DBEdit оно отображено будет все равно только как 'аб'.
Уважаемые форумчане, что это такое и как с этим бороться?
- Little_Roo
- энтузиаст
- Сообщения: 639
- Зарегистрирован: 27.02.2009 18:56:36
- Откуда: Санкт-Петербург
для русских символов увеличь длину поля вдвое - varchar (8)
Да я так уже думал сделать, но решил спросить - может есть какое-то нормальное решение? А то из-за такой непонятной ерунды во всей базе длину полей увеличивать...
- Little_Roo
- энтузиаст
- Сообщения: 639
- Зарегистрирован: 27.02.2009 18:56:36
- Откуда: Санкт-Петербург
kostyan29 писал(а): А то из-за такой непонятной ерунды во всей базе длину полей увеличивать...
Это не ерунда, это UTF
Little_Roo писал(а):Это не ерунда, это UTF
Это не ерунда, а старый баг - ДБ-классы из FCL не умеют работать с UTF-8
kostyan29 писал(а):может есть какое-то нормальное решение?
Если доступ к базе через ZEOS, то поставь версию ZEOS из trunk - она не обрезает символы.
- Little_Roo
- энтузиаст
- Сообщения: 639
- Зарегистрирован: 27.02.2009 18:56:36
- Откуда: Санкт-Петербург
hovadur писал(а):поставь версию ZEOS из trunk
Угу
Little_Roo писал(а):Угу![]()
![]()
А что? Я обновляю версию ZEOS из trunk каждые полгода и так уже 3 года в продакшен у меня уходит. Недавно начал переводить базу в utf8, обнаружилась бага, что у топикарстера, обновил trunk. Продолжаем работу.
- Little_Roo
- энтузиаст
- Сообщения: 639
- Зарегистрирован: 27.02.2009 18:56:36
- Откуда: Санкт-Петербург
hovadur писал(а): что? Я обновляю версию ZEOS из trunk каждые полгода
Ну-у-у-у-ууу.....
Только что - svn 2510
И в чем баг? Конвертация в zeos-е нормально работает - у меня база в ср1251-> открывается нормально, и работа с ней тож.... Главное, чтоб в TZConnection.Properties была бы строчка
codepage=UTF8
Или мы все не о том???
Little_Roo писал(а): Там почти кажинную ночь обновления
Нет, в trunk они мержат изменения в testing, вот там-то в testing изменения каждую ночь, а в trunk только несколько раз в месяц, а могут и два месяца не трогать trunk. svn 2510 сейчас в testing-7.2, trunk там svn 2507.
Little_Roo писал(а):Или мы все не о том???![]()
![]()
Не знаю, вероятно, это какой-то специфичный баг, проявлялся только когда все в utf8, и база и окружение.
- Little_Roo
- энтузиаст
- Сообщения: 639
- Зарегистрирован: 27.02.2009 18:56:36
- Откуда: Санкт-Петербург
hovadur писал(а): а в trunk только несколько раз в месяц, а могут и два месяца не трогать trunk.
Не правда ваша
http://svn.code.sf.net/p/zeoslib/code-0/trunk
Постоянно обновляется...
Little_Roo писал(а):Постоянно обновляется...
Это обновляется testing. По http показывается последняя ревизия, существующая в svn. Если сделать svn co http://svn.code.sf.net/p/zeoslib/code-0/trunk, а потом сделать svn info, то показывается 2507.
