[ОТВЕТИТЬ]
Опции темы
03.02.2012 11:17  
OlegON
можно и oracle пропатчить... клиентский. до 10.2.0.5
 
03.02.2012 11:20  
Mr_Vito
я сделаю, но сомневаюсь, что поможет, т.к. и с девяткой тоже самое :(
и вообще винду переставлю :(
 
03.02.2012 12:04  
Mtirt
Я подозреваю, что речь вот об этом внутреннем буфере:
 
20.02.2012 09:58  
Mr_Vito
во общем проблема решилась, благодаря ораклисту из С+ (спасибо ему)
оказалось, что язык базы данных:
AMERICAN_AMERICA.CL8MSWIN1251
а в реестре на клиентских машинах было прописано:
RUSSIAN_CIS.CL8MSWIN1251

после того как пере прописал в реестрах на клиентах кодовую страницу, супермаг вылетать перестал :)
 
20.02.2012 10:13  
OlegON
Очень смешно. Баг Супермага записали? Так и еще багов наловить недолго. Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения и на клиентах должно быть RUSSIAN_CIS. Пусть СМ не пхает мусор. У тебя сейчас могут начаться танцы с точками и запятыми.

Кстати, в 2003м где-то от этого падал почтовик.
Для примера можно еще удивиться английскому написанию месяцев в select sysdate from dual (у тебя есть самописные отчеты?), потом куча геморроя будет, если есть какой-это тупенький экспорт-импорт, где есть дробные числа (привет, каша с десятичным разделителем). В общем, я категорически против америки на клиенте. И ровно настолько категорически за америку на сервере.
 
20.02.2012 16:05  
deepdiver
Цитата:
Сообщение от OlegON
Очень смешно. Баг Супермага записали? Так и еще багов наловить недолго. Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения и на клиентах должно быть RUSSIAN_CIS. Пусть СМ не пхает мусор. У тебя сейчас могут начаться танцы с точками и запятыми.

Кстати, в 2003м где-то от этого падал почтовик.
Для примера можно еще удивиться английскому написанию месяцев в select sysdate from dual (у тебя есть самописные отчеты?), потом куча геморроя будет, если есть какой-это тупенький экспорт-импорт, где есть дробные числа (привет, каша с десятичным разделителем). В общем, я категорически против америки на клиенте. И ровно настолько категорически за америку на сервере.
Олег, я не уверен что это баг СМ+, т.к. текущий опыт других организаций показывает что такой ошибки не возникает при соответствии кодировок.
По этому работая Mr_Vito исследовал разные варианты и в итоге выяснили что проблема в несовпадении кодировок базы и клиента.
В итоге получалось у БД формат даты ММ.ДД.ГГГГ, а у клиента ДД.ММ.ГГГГ. и для объективности прошу приводить примеры и результат, а не общие слова которые все видят выше.
В результате имеем решенную конкретную проблему, и этот опыт в будущем думаю поможет кому то не мучится долго и не лезть в дебри.

Предполагаю одно из не главных предназначений этого форума в том что бы помогать решать такие не совсем понятные проблемы, которые так и говорят - "а свали на производителя ПО, пусть он решает проблему, но не на самого себя который что то неправильно сделал".
Предлагаю быть более объективным насколько возможно в этом субъективном мире, а не обвинять всех и вся.
 
20.02.2012 16:27  
OlegON
Я максимально объективен. Цитирую результаты запросов, получаемых на клиенте в результате установки америки.

Цитата:
SQL> select sysdate from dual;
SYSDATE
---------
20-FEB-12

SQL> select to_char(sysdate,'DD MONTH YYYY') from dual;

TO_CHAR(SYSDATE,'DDMONTHYYYY')
---------------------------------------------------
20 FEBRUARY 2012

SQL> select 1/2 from dual;

1/2
----------
.5
проблема не в том, что мне не нравится, что производитель ПО предлагает клиенту ставить костыль, как в данном случае, а в том, что этот костыль может потребовать кучу дополнительных костылей, потому, что он кривой...
Основной тезис я написал выше: "Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения". Прошу привести доводы в пользу твоего высказывания, что Mr_Vito что-то неправильно сделал. Что именно? Я без наезда потому, что данную проблему не решал, но хочу открыть для себя что-то новое, чего, как думаю, на самом деле не происходило.
Я подозреваю, что где-то в коде СМ дата передалась, как строка, а не как дата, избежав соответствующей конверсии. В результате и получалась дуля с маслом, а не результат. Это я и называю багой.
 
12.06.2013 05:30  
Tiger
Не получается решить проблему, с помощью решения предложенного выше! Причем ошибка появляется на разных компьютерах, ОС -Windows 7! Может появились иные способы решения этого бага?
Миниатюры
Нажмите на изображение для увеличения
Название: Ошибка.jpg
Просмотров: 397
Размер:	171.1 Кб
ID:	2032  
 
12.06.2013 10:44  
Troll
А что говорит вывод запросов выше в sqlplus на клиенте? Как NLS выставлял?
 
13.06.2013 04:01  
Tiger
Цитата:
Сообщение от Troll
А что говорит вывод запросов выше в sqlplus на клиенте? Как NLS выставлял?
NLS_LANG исправил в реестре, там где встречалось RUSSIAN_CIS.CL8MSWIN1251 заменил на AMERICAN_CIS.CL8MSWIN1251!

Вот результат выполнения команд (на 1-ом скриншоте - RUSSIAN_CIS.CL8MSWIN1251, на 2-ом - AMERICAN_CIS.CL8MSWIN1251)
Миниатюры
Нажмите на изображение для увеличения
Название: RUSSIAN.jpg
Просмотров: 363
Размер:	51.5 Кб
ID:	2036   Нажмите на изображение для увеличения
Название: AMERICAN.jpg
Просмотров: 359
Размер:	90.1 Кб
ID:	2037  
 
 


Опции темы



Часовой пояс GMT +3, время: 01:26.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.