Serg0JDBC, как впрочем и все остальное, смотрит не на QCCSID и прочая, а на CCSID поля в файле (если при создании PF не описаны CCSID на отдельные поля, то они совпадают с CCSID PF).

Если работа с этими таблицами идет в одной connection, то ничего кроме как использовать
varchar(..., ..., 1025) для полей с CCSID 37 не остается.

Есть еще извращенный вариант - корректировка-хак таблиц преобразования для CCSID 37 в Client Access, но это того не стоит.

почему не стоит? у нас долго такой метод использовался
только он не работает если часть таблиц в 37 а часть в 1025
но самый правильный вриант - переделать все в нужную кодировку пока поздно не стало..
если таблицы создавались через dds то достаточно просто сделать chgpf

Serge Reva

ДжекНепотрошительДобрый день, коллеги
Возникла такая проблема: есть iSeries, есть таблички. Причем часть из них имеет CCSID 37, а часть - 1025. Такой бардак сложился исторически, и изменить его нет возможности, т.к. с первыми работает одна покупная софтина, которой подавай именно 37, со вторыми - другая, которой надо именно 1025.
И есть приложение, из которого надо работать с табличками обеих кодировок через JDBC. При этом русские символы из 1025 преобразуются корректно, из 37 выходят кракозябры.
Вопрос: откуда JDBC берет дефолтовую кодовую страницу для своего преобразования (пробовал менять системную переменную QCCSID, на нее он не реагирует :- ), и можно ли ее переопределить хотя бы для одного текущего JDBC-коннекта (а в идеале - для конкретного резалтсета)?
Заранее благодарю

о, так ето дядя женя..
боже ш мой, наше песнтя хороша начинай сначала

Serge Reva