Доброго всем времени суток.
Может кто сталкивался с такой проблемой.
Есть база в Калининграде (консолидирована) и в Утене (удалённая).
В Калин. вся локалка на русском и сама база васползует 1251CYR.
В Утене вся локалка на литовском но база васползует тоже 1251CYR для репликации между собой. Эта понятно )) .

Возникла токая проблема, когда высылается сообщение с русским текстом в Утену по SMTP протоколу, то в Утене отображается не на русском.
Посоветуйте как обойти эту проблему не меняя локалку (так как много что кружится на этом сервере)

Благодарен за ранее.

Модератор: я верю в силу ваших чувств, но матерится все же не нужно

Вот втом и проблема что переключить нельзя.
Как тестировал в офисе то на двух русских локалках работает, замечятелно.
Если переключить локалку то слово которое было отослано ранее останется не заменённым, так как оно сканвертировалось. На изменённую локаль надо высылать сообсчение повторно, тогда оно нармална сработает (не заменит русских символов).
Надо както обойти.
Проблема как я думаю састоит в СQЛ запросе который высылается по СМТП кодированным. И одконвертить зависит од лакали. Какта надо это обойти, но нзн как...
Есть какие предложения?

Понятно.
Локаль как и писал више полнастю литовская.
Вместо скрина напишу то что высылаю и то что сахраняетса в одолённой базе.
" Обнавдён. ID= " получаю " iikiaeak. ID= "

Вы пишете что праблема с базай. Может праблема в том, что я скопировал консолидированую базу на адалённый компютер и там сконфигуриравал заного? думаю нет, так как символы руские сахранились, тока проблема возникла когда принимаетса запрос высланный консолидированой базай.
Что именно получаю написал.

White OwlТак, давай по пунктам.
1) Данные хранятся в консолидированной базе в какой кодировке? CP1251?
2) Какой charset указан в строке коннекта которым dbremote подключается к консолидированной базе? Если ни какой не указан - dbremote возьмет кодировку из OS на которой он запущен. И если кодировка в коннекте dbremote не совпадает с кодировкой сервера, текст будет перекодирован. Либо сервером (если у вас ASA9 и выше), либо ODBC драйвером если у вас ASA8 или ниже.
3) dbremote получив данные уже никогда не занимается перекодировкой, он ужимает данные встроенным архиватором и через SMTP/FTP/etc идет бинарный пакет, которому кодировки до лампочки.
4) Получающий dbremote распаковывает полученный пакет и превращает его в текст. А дальше повторяется тоже самое что на этапе отправления. Если у получающего dbremote в строке коннекта charset явно не указан, он будет равным локали ОС. И если итоговый charset для коннекта dbremote не совпадает с основной кодировкой получающей базы текст будет переконвертирован перед помещением в собственно базу.
А теперь проследи путь своих данных и подумай на каком этапе, куда они переконвертируются...

dbremote это обычный клиент, он ведет себя точно так же как и любая другая клиентская программа.

Ваши пункты много говорят о решении проблемы )))
Так как уменья в одну сторону, то проблемы возникают тока в оддолённой.
Ответы на ваши пункты.

1) 1251ЦиР
2) dbremote -o E:\DB\remote_log.txt -c "eng=???;uid=???;pwd=???" , как видна не указал..., если не трудно, какой нужна указать charset?
3) понятно
4) понятно

Спасибо, уже чтото выясняется...

Живём и учемся )))

White Owl evigisВы пишете что праблема с базай. Может праблема в том, что я скопировал консолидированую базу на адалённый компютер и там сконфигуриравал заного?Что значит "сконфигруировал заново"?
При простом копировании файла базы данные какими были, такими и останутся. А вот доступ к этим данным уже будет зависеть от приходящих к серверу клиентов.

PS Орфографического словаря под рукой нет вообще?

Ползуюсь транслитом )))

charset забыл указать, извините cp1251

Безумно благодарен. Проблема решена )))