Проблема с fetch. размером поля, UTF8 и русскими буквами

[arhip]

Проблема с fetch. размером поля, UTF8 и русскими буквами

Всем привет!
Сейчас у меня стоит PHP 5.0.2. Oracle 8.1.7.какой-то там
В apachectl прописано
export NLS_LANG=RUSSIAN_CIS.UTF8

Есть колонка с таблице varchar(20). В ней только русские символы. Если я выбираю из этой колонки и у меня запись больше 10-ти символов, то oci_fetch_all устанавливает значение поля в bool(false).
Проверьте плиз как у кого. Может быть, это исправлено в последней версии?

Если это важно, то fetch я делаю по строкам.
Спасибо.

 

[tony2001]

>oci_fetch_all устанавливает значение поля в bool(false).
*возвращает* false для этого поля?
остальные (oci_fetch_*) тоже?

 

[arhip]

Как минимум, fetch_object устанавливает значение тоже в false:

object(stdClass)#4 (8) {  
  ["id"] =   string(3) "144"  
  ["firstName"] =   string(14) "Алексей"  
  ["lastName"] =   string(16) "Шевченко"  
  ["middleName"] =   bool(false)  
  ["office"] =   string(20) "Софиевская"  
  ["telOffice"] =   string(4) "2222"  
  ["telMobile"] =   string(9) "222-22-22"  
  ["isActive"] =   string(1) "0"
}

 

[tony2001]

нет, "как минимум" не хватит.
попробуй, плз, все остальные функции тоже, это 3 секунды дела.
будет совсем отлично, если ты еще и попробуешь последний снэпшот 5.0.x, на всякий случай.

если все так же - заводи баг-репорт на bugs.php.net.
и не забудь описать свою систему и приложить reproduce script.

 

[arhip]

oci_fetch_all - false
oci_fetch_array - false
oci_fetch_assoc - false
oci_fetch_object - false
oci_fetch_row - false

Пока нет возможности проверить на снепшоте. Если можешь - посмотри у себя плиз.
Спасибо.

 

[tony2001]

вряд ли я смогу найти древний Оракл, да еще и с NLS_LANG UTF8.
заводи баг-репорт.

 

[arhip]

Кому интересно, заведен баг №31042

Но, насколько я понял, в сегодняшний релиз патч не попал.

-~{}~ 10.01.05 13:26:

Тони, ты мне конечно патч прислал, но. Когда будет в CVS'е? ))

Или уже есть

 

[tony2001]

arhip
нет, пока в CVS нет.
проблема в том, что умножать на 6 мне как-то не очень хочется.
а другого выхода не могут предложить даже люди из OCI Development Team.
кстати, по поводу определения кодировки "UTF или нет" - они тоже не могут ничего предложить.
есть другие идеи?

 

[arhip]

Ну... у меня была только идея с NLS_LANG.
Ты говорил, чо в 9-ке и выше мы знаем только ID - им можно оперировать? интересно бы узнать как сделали в SQLPlus'е - в нем работает все корректно.

 

[tony2001]

>Ну... у меня была только идея с NLS_LANG.
>Ты говорил, чо в 9-ке и выше мы знаем только ID - им можно оперировать?
я их спрашивал про это тоже. Цитата из ответа:

I checked recently with the NLS team and there is no
easy way to do this for bind variables.

>интересно бы узнать как сделали в SQLPlus'е - в нем работает все корректно.
вполне возможно, что умножают на 6 =)

кстати, если поискать по инету по коду ошибки, то там умножают длину кто на что горазд - кто на 4 умножает, кто на 3..

 

[arhip]

Хе-хе-хе!
У кого сколько памяти - то на столько и умножает

 

[si]

а разговаривал с одним человеком, который писал некий софт с OCI, он сказал что они опытным путем нашли что умножать надо на 3. хотя чисто теоретически этого тоже может быть недостаточно.

 

[tony2001]

si
проблема в том, что человек может себе не представлять безграничные возможности пользователей PHP =)
я могу оставить 3, скажем, но через месяц придет какой-нибудь индиец и будет жаловаться, что его Хинди в UTF из базы не забирается..

 

[arhip]

Тут поступило предложение вынести в крнфигурационый скрипт опцию, с помощью которой можно определить насколько больший буфер использовать

 

[tony2001]

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