Вобщем вот так у меня заработало в тестовом сервлете, и вставляет русские буквы (проверял в стороннем приложении в эту базу лазающем - буквы в таблице русские) и вынимает:



У вас должно и нормальное соединение зажить:


У меня jdbc:oracle:oci не живёт из-за небольшого насилия над базой по части юникода в varchar2 - ломается на длине русских строк. Похоже в штатном oci-клиенте до сих пор присутствует непонимание того, что буквы бывают длиннее одного байта. В общем было бы интересно узнать - заживут ли у вас оба драйвера.


Для теста использована таблица простейшей структуры:


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



Это сообщение отредактировал(а) 3x3 - 22.9.2006, 03:56

А в БД какая кодировка настроена?

UTF-8.
У меня сейчас европейский eXpress Edition стоит, русского NLS там нет вообще. Т.е. русских чарсетов нет, русской сортировки нет (не проверял, кстати), русских сообщений нет, русских дат нет. И UTF-8 я ему насильно прописал, только что-б буквы русские попробовать.

Без перекодировки (т.е. пришло в UTF8 и сохраняется в UTF8) - хоть русские буквы засовываются. Хотя varchar2 при этом считает длину не по количеству символов, а по количеству байтов, т.е. макс.допустимое количество букв в строке будет ниже указанного при создании таблицы ровно в два раза. Что бы в длине строк не зависеть от кодировки, с 9й версии можно задавать поля в символах:
    create table t 
      (  x varchar2( 20 CHAR ),
       ...
    )




Вам собственно нужно провести 2х3 экспериментов: используя oci и thin драйвера с кодировками как у Базы, UTF-8 и какую-нить 8-битную какую ваша Java понимает, 1251 например. При этом, на всякий случай, выставляйте соответствующий NLS_LANG и в окружении процесса.


Это сообщение отредактировал(а) 3x3 - 28.9.2006, 16:58

АААААААА!!!!!!!!
Кажись заработало! Спасибо огромное!!!!!!!

Ну так поделитесь чего и как заработало в вашей конкретной конфигурации. На будущее може ещё кому пригодится.

Пример 3х3 заработал.

ОК. По всей видимости из-за вот этого:
prop.setProperty("NLS_LANG", "AMERICAN_AMERICA.UTF8");

Тогда как резюме:

ИМХО можно сделать вывод, что thin-драйвер не полагается на настройки на клиенте - ведь он может и из апплетки работать на клиенте, который или настроен неправильно или вообще не знает про существование Oracle. Т.е. он полагается на дефолтные настройки базы, но ничего про ISO-8859-5, видимо, не знает - т.е. JVM не имеет установленных правил трансляции этой кодировки в юникод. 

Задав параметры соединения явно, вы указали базе во что она должна транслировать буквы перед отправкой их на клиента. Если это так, то вместо UTF8 должна бы и CL8MSWIN1251 работать, если она установлена на сервере БД и поддержана клиентской джавой.