Собственно говоря, что я сделал... Взял БД от M$ Access, поискал чем его можно пооткрывать в стиле
M$-технологий... то, что получилось, я "свел" в этом постинге.

ВНИМАНИЕ! Не стоит пытаться подстрелить меня из рогатки с оптическим прицелом и глушителем.
Я ПРЕКРАСНО знаю, что работа с файлом от M$ Access средствами ODBC -- бред, т.к.
файл Access'а относится к ISAM-файлам (Index-Sequence Access Method), для работы с которыми есть
все-таки технология DAO (Data-Base Access Objects) от того же M$, но... Ну нет у меня "под рукой" M$ SQL
Server'а, а ставить -- а не ну ли его на фиг? Чтобы потом "сносить"? Вот и тестировал на том, что было.

Хэх! Как верно заметил Olej в одном из своих постингов, работа с ODBC из UNIX -- только для тех,
"кто понимает толк в истинных извращениях". Добавлю от себя что и вообщем-то ODBC, даже в M$ Windows
никогда не были самым удобным интерфейсом, ни в С, ни, тем более, в С++. Хотя, справедливости
ради, надо заметить, что все остальное (в том числе и основанное на ODBC) -- еще хуже, т.к. ODBC
(по крайней мере, если прочесть именно о самой идее ODBC), еще более-менее "прозрачный" интерфейс.
И учесть довольно "малоглюкавую" реализацию, что для M$, согласитесь, отнюдь не типично. Хотя, подчас
работать с ODBC -- "истинное удовольствие"...

Как пример UNIX'овского подхода к делу, могу привести практически любую БД под UNIX (от Oracle до
PostgreSQL и SAP DB), в которых считается правилом хорошего тона предоставлять не один, а ряд инструментов:
- это и библиотеки доступа к БД, основанные на "Embedded SQL". В этом случае Вы пишете некий "промежуточный"
код из SQL и С, "скармливаете" его препроцессору из состава БД и на выходе получаете С-модуль, реализующий
SQL-запросы к БД по Вашей "спецификации".
- Это и библиотеки "прямого доступа" к данным для БД...
- Библиотеки работают как с С, так и с С++, Perl, Java... Собственно, можно делать что угодно, как угодно
и при помощи каких угодно инструментальных средств.

Да, собственно, много чего есть в UNIX для работы с БД. По этой причине, человеку, пришедшему из
мира Windows, можно слегка ошалеть, только прочитав документацию на нормальную БД.

Ладно. Что нам-то делать? Т.к. глюки глюками, а доступ к тому, что M$ называет "базами данных" все-таки
надобно поиметь.

Вариант #1 -- iODBC.
Поддерживается ряд платформ:


Как работает.
Так же как и ODBC в "чистом виде". Есть некий промежуточный слой, к которому обращается прикладная программа.
Через этот слой идет обращение к "драйверу БД", который транслирует SQL-запрос серверу БД. Сервер БД чего-то
делает и возвращает результаты по обратной цепочке. Драйвера к той или иной БД представляют собой библиотеки.

Все бы было хорошо, еслиб не было так плохо. Проблема в драйверах. Дело в том, что та "контора", которая
разработала все это дело, разрабатывает и драйвера для БД, причем, "кросс-платформенные". И распространяет
их на коммерческой основе. Хотя, в принципе, демо-версии дров получить можно и, вроде, даже во времени они
не ограничены, но, по-моему, с функциональностью у них есть некоторые "напряги". По крайней мере, драйвер
для M$ Access слегка кривоват. Или мне просто показалось... Ничего не собираюсь утверждать.

Дополнительные ссылки:
- http://www.iodbc.org -- сам по себе проект.
- http://www.openlinksw.com -- драйвера, распространыемые на коммерческой основе.

Минусы -- самый, пожалуй главный -- проблема с дровами. Второй "минус" -- рекомендуется править файл
~/odbc.ini "врукопашную". Нет, не то, что бы я был против... Но... Есть вариант и по-лучше...
Уж "развлекаться", так по полной... :D

Вариант #2 -- unixODBC.
Поддерживается весь тот же ряд платформ, но, плюс еще и QNX.

Как работает.
Все точно так же, как и предыдущий вариант -- за исключением одного "но" -- для доступа к БД, расположенным
под Windows, Вам понадобится "мост" ODBC-ODBC. Т.е. этот мост становится в unixODBC "универсальным драйвером"
БД, к которому идет обращение со стороны "промежуточного слоя ODBC" за данными, о которых известно, что они
расположены под Win32.

Если данные расположены под UNIX, то unixODBC работает через свои драйверы. Т.е. unixODBC привносит в UNIX
методику работы с БД из Win32. Этому уродству есть только одно объяснение. IMHO, если софтина должна
работать с данными как под Win32, так и под UNIX, то проще в этой софтине использовать пусть и корявый, но
единый интерфейс, нежели развлекаться с двумя вариантами.

Дополнительные ссылки:
- http://www.easysoft.com -- менеджер для unixODBC и "мост" ODBC-ODBC. Последний -- trial 30-day edition.
- http://sourceforge.net/projects/unixodbc/ -- AS IS.
- http://www.unixodbc.org/

Минусы -- все то же желание разработчиков получить с нас денежку, но это, IMHO, не всегда и плохо. Но здесь,
IMHO, налицо случай явного и принудительного инфицирования разработчиков "зеленой лихорадкой" имени Гейтса.

Плюсы -- большая открытость и продуманность как интерфейса и средств управления, так и драйверов, к примеру,
есть драйвера для Internet News Server. Есть шаблон драйвера (для желающих). Видел драйвер для InterBase.
К этой "базе данных" у меня особотрепетное отношение. Когда-то программисты в той конторе, где я работал
админом, на голой груди все волосы голыми руками по-вырывали за этот IB. Дело кончилось переходом на M$ SQL.

Далее. Есть, правда консольное, но средство построения sql-запросов к ресурсам, определенным в ~/odbc.ini.
Позволяет довольно быстро и качественно конструировать запросы. Вполне возможно русифицировать "конфигураторы"
"источников данных" -- я про DataManager'ы и ODBCConfig. Они писаны на С++, с применением Qt (KDE).

Как выглядит прога, использующая *ODBC?
Да как почти обычное Win32 С-приложение, с ТакимЖеВотСинтаксисом. С теми же SQLExec(...), SQLAllocStmt(...),
SQLFreeStmt(...) и т.д. и т.п., т.к. сами по себе средства *ODBC ничего не стараются менять в исходном тексте,
портируемом из Win32. Библиотеки есть для С и С++. Так что, если есть опыт развлечений с ODBC в Windows и
рука не дрогнет "отслюнить" какие-то деньги за софт под *NIX, то... Вам виднее...

Сейчас вот перечитал написаное -- может, все-таки WinE использовать? В любом случае, лично мне не очень
понравились ни первый ни второй варианты. Буду пробовать. А пока, скажем так, "затычка" для задачи есть. IMHO,
за тридцать-то дней чего-нибудь придумаю... Хотя, может, у кого какие идеи есть?