Доброе время суток. Столкнулся с такой проблемой. Потребовалось получить с сервера под Дебианом х64 доступ к Cache по ODBC. Поставил unixodbc, unixodbc-dev. Скачал крайний драйвер с официального сайта Интерсистемс (Cache.5.0.21.ODBC-6408-linuxamd64.tar.Z). Распаковал, запустил скрипт. Отредактировал файл cacheodbc.ini, сгенерированный в каталоге mgr:


После этого тестовый скрипт из каталога dev/odbc/samples/select/ select.sh отлично работать. Я немного рихтую его до вида:

И начинаются проблемы. Там есть несколько колонок, содержащих русские символы. Символы отображаются корректно. Но вот столбцы начинают склеиваться. Т.е. такое ощущение, что драйвер не видит конца поля записи и пишет следующее. Более того, зачастую слетает кодировка самой консоли (и русские, и английские буквы после выполнения скрипта отображаются некорректно). При попытке порабоать с соединением через библиотеку OTL наблюдается то же самое. Символы кодированы UTF8. Если есть русский, то поле заканчивается символами 0x03 0x01 (или другими служебными) и дальше в него попадает фрагмент следующего и т.д. Как следствие, библиотека постоянно падает с segmentation fault из-за некорректного определения конца строки, как мне кажется. Доводилось ли кому-либо работать с подобной связкой? Как заставить драйвер корректно отдавать данные?

Пример вывода по одному стобцу с кириллицей:

В общем, проблему решил костылем. Для OTL указывал предельное количество байт для char-полей, чтобы избежать segmentation fault при чтении:


Со склеенными записями пришлось бороться поиском любых мусорных символов с кодами ниже 0x20 и заменой на 0x00.
После этих манипуляций строки стали пригодны для работы с ними стандартными функциями.

Блок А.Н., что вы имеете ввиду под правильной декларацией? Проблема была в том, что возвращаемые драйвером строки не имели \0 на конце, т.е. не были валидными Си-строками.

Более того, драйвер оказался крайне бажным. От ОТЛ пришлось отказаться, потому что select, возвращающий количество записей более одной вообще корректно не работал. Выглядело это так:
1) Запрашиваем набор данных, который должен вернуть 12 записей.
2) Вместо этого нам возвращается первые 6 из них, перемежающиеся пустыми записями:

Пришлось отказаться и использовать голый ODBC. В итоге уперся в то, что драйвер из базы преобразовывал cp866 в UTF8 без спросу, а при insert/update этого не делал, запихивая в cache utf-8. При этом однобайтовые кодировки нещадно резал, заменяя символами '?'. Проблемы решились использованием драйвера для версии 5.2 ссылко. Работает и с iODBC и с unixODBC. Пруф здесь .