Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > Супермаг Плюс (Супермаг 2000)

формат даты слишком велик для внутреннего буфера : Супермаг Плюс (Супермаг 2000)

19.03.2024 9:47


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
Просмотров: 573
Размер:	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
Просмотров: 595
Размер:	51.5 Кб
ID:	2036   Нажмите на изображение для увеличения
Название: AMERICAN.jpg
Просмотров: 554
Размер:	90.1 Кб
ID:	2037  
Часовой пояс GMT +3, время: 09:47.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.