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

можно и oracle пропатчить... клиентский. до 10.2.0.5

я сделаю, но сомневаюсь, что поможет, т.к. и с девяткой тоже самое :(
и вообще винду переставлю :(

Я подозреваю, что речь вот об этом внутреннем буфере:
[ ➜ ]

во общем проблема решилась, благодаря ораклисту из С+ (спасибо ему)
оказалось, что язык базы данных:
AMERICAN_AMERICA.CL8MSWIN1251
а в реестре на клиентских машинах было прописано:
RUSSIAN_CIS.CL8MSWIN1251

после того как пере прописал в реестрах на клиентах кодовую страницу, супермаг вылетать перестал :)

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

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

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

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

Я максимально объективен. Цитирую результаты запросов, получаемых на клиенте в результате установки америки.

проблема не в том, что мне не нравится, что производитель ПО предлагает клиенту ставить костыль, как в данном случае, а в том, что этот костыль может потребовать кучу дополнительных костылей, потому, что он кривой...
Основной тезис я написал выше: "Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения". Прошу привести доводы в пользу твоего высказывания, что Mr_Vito что-то неправильно сделал. Что именно? Я без наезда потому, что данную проблему не решал, но хочу открыть для себя что-то новое, чего, как думаю, на самом деле не происходило.
Я подозреваю, что где-то в коде СМ дата передалась, как строка, а не как дата, избежав соответствующей конверсии. В результате и получалась дуля с маслом, а не результат. Это я и называю багой.

Не получается решить проблему, с помощью решения предложенного выше! Причем ошибка появляется на разных компьютерах, ОС -Windows 7! Может появились иные способы решения этого бага?

Миниатюры

 

А что говорит вывод запросов выше в sqlplus на клиенте? Как NLS выставлял?

NLS_LANG исправил в реестре, там где встречалось RUSSIAN_CIS.CL8MSWIN1251 заменил на AMERICAN_CIS.CL8MSWIN1251!

Вот результат выполнения команд (на 1-ом скриншоте - RUSSIAN_CIS.CL8MSWIN1251, на 2-ом - AMERICAN_CIS.CL8MSWIN1251)

Миниатюры