8.х Кодировка в dsn для подключения к MySql

Тема в разделе "Конфигурирование на платформе "1С:Предприятие 8"", создана пользователем anyuta, 28 авг 2014.

  1. TopicStarter Overlay
    anyuta
    Offline

    anyuta Опытный в 1С

    Регистрация:
    22 июн 2011
    Сообщения:
    333
    Симпатии:
    0
    Баллы:
    26
    Добрый день! Конфигурация самописная, 8.3.5. Сервер на ОС Linux, на нем установили ODBC драйвер, создали dsn. В конфигураторе создали внешний источник данных, все подключилось, таблицы отображаются. Проблема в кодировке...элементарно, делаем запрос к таблице внешнего источника данных, даты и числа отображаются нормально, а вот строка вида 2_4245 преобразуется к виду 244 (даже не 242). Пожалуйста помогите решить проблему. Я так понимаю, если в dsn задана определенная кодировка, то уже в строке подключения бесполезно писать строку вида: STMT=SET CHARACTER SET cp1251? В dsn пытались разные кодировки прописывать, безрезультатно. Может после изменения настроек dsn нужно какую-то службу/процесс перезапустить?
    Я выполнила код: show variables like "char%"; Получила следующий результат

    "character_set_client";"latin1"
    "character_set_connection";"latin1"
    "character_set_database";"latin1"
    "character_set_filesystem";"binary"
    "character_set_results";"latin1"
    "character_set_server";"latin1"
    "character_set_system";"utf8"
    "character_sets_dir";"/usr/local/share/mysql/charsets/"

    Таблицы в MySQL у меня в кодировке cp1251. Сильно не пинайте, базу MySQL вел до меня программист, работаю с тем, что есть. Может при получении данных из внешнего источника можно каким-то образом кодировку установить? Что можно попробовать сделать, в чем может быть проблема?
  2. Rem_32
    Offline

    Rem_32

    Регистрация:
    27 июл 2015
    Сообщения:
    3
    Симпатии:
    0
    Баллы:
    1
    Добрый день! Столкнулся с похожей ситуацией: 8.3.6 + КА2.0 на Debian, для обменов с внешней базой поставил unixodbc + odbc-postgresql, прописал все драйверы и dsn (везде и на сервере 1с и на внешней базе разрядность х64 и кодировка Unicode) и точно так же во внешнем источнике данных любая строка на любом языке отображается через символ... хотя в консольке isql на сервере 1с все запросы к внешней базе отображаются корректно...

    Ковыряния odbc успехов также не дают. У вас получилось решить эту проблему?
  3. TopicStarter Overlay
    anyuta
    Offline

    anyuta Опытный в 1С

    Регистрация:
    22 июн 2011
    Сообщения:
    333
    Симпатии:
    0
    Баллы:
    26
    Добрый день! К сожалению, данную проблему не решили. Изобретали велосипед, строку записывали с пробелами, т.е. 2 _ 4 2 4 5, пробелы удаляются, и получаем то, что нужно. Понимаю, что хуже некуда сделано, но по-другому не решили вопрос.
  4. Rem_32
    Offline

    Rem_32

    Регистрация:
    27 июл 2015
    Сообщения:
    3
    Симпатии:
    0
    Баллы:
    1
    Спасибо, что ответили!
    Проверил - действительно такой велосипед выдает желаемое за действительное :). к сожалению, внешней базой пользуется не только 1с, поэтому в таком виде данные хранить не сможем. будем искать другие варианты...
  5. AlexTr
    Offline

    AlexTr

    Регистрация:
    30 сен 2015
    Сообщения:
    1
    Симпатии:
    0
    Баллы:
    1
    Столкнулся с этой проблемой. Вот ответ из 1С:

    Данная ошибка известна и зарегистрирована под номером 10143774.
    Исправление будет доступно в платформе 8.3.7

    Обходное решение: В некоторых дистрибутивах Linux присутствует обновленный unixOBDC (без SQL_WCHART_CONVERT). В таких случаях платформа 1С при работе с таким драйвером может пропускать символы в текстовых полях. В CentOS 6 данный драйвер собран с SQL_WCHART_CONVERT. В нем ошибка не воспроизводится. Также можно использовать провайдер iODBC, однако его необходимо собирать самостоятельно из исходников.
    Поэтому основная рекомендация – использовать CentOS
Похожие темы
  1. Snake-84
    Ответов:
    2
    Просмотров:
    1.618
  2. Dmitrij

    Курилка Кодировка

    Dmitrij, 17 сен 2008, в разделе: Курилка
    Ответов:
    6
    Просмотров:
    1.446
Загрузка...

Поделиться этой страницей