а) Он теперь полностью подружился с кириллицей (верно для SQLite3, т.е. юникодных баз), причем как на уровне полей, так и на уровне таблиц, запросов, псевдонимов. За это ответила "флажочка" OEM CP.

б) Нет никаких проблем с получением/записью через него данных в БД в важных приложениях:
- MS Excel и Access 2003, 2007, 2010
- OpenOffice/LibreOffice 2.4-3.X
Появилась заманчивая перспектива НЕ хранить данные в Excel вообще а тупо их в него читать через ODBC параметрическим запросом, причем рисовать параметры можно развитым инструментарием Excel (выпадающие списки с проверкой итп). По сути это способ отказаться от Access или просто строить небольшие информационные системы на основе СПО (OO/LO Calc + ODBC + SQLite). Производительность при индексах примерно в 2 раза выше, чем с файлом MDB (работа на SSD-диске).

в) Производительность запросов "мимо" ODBC и через него, напрямую, отличается крайне незначительно.

г) Все это работает и под Linux, а это впервые означает, что можно делать настоящие офисные кросс-платформенные приложения, безо всяких швайнов и прочей возни

д) Автор, тов. Christian , регулярно, почти ежемесячно релизит новые версии со свежим sqlite, и все это лежит в

...
А теперь, собсна вопрос: научился ли кто загружать расширения в него, с помощью вкладки в Администрирование - ODBC - Load Extension, и как это сделать? Это позволило бы стать движку SQLite абсолютно стандартным компонентом любого рабочего места, поскольку лучшего способа однофайлового хранения не существует (особенно на сжатом SSD-диске).

... лежит в http://www.ch-werner.de/sqliteodbc/

RXL, имеется ввиду что после установки любого ODBC - драйвера - в Настройках (Панель управления Windows) появляется возможность задать некоторые настройки этого драйвера (в том числе национальные особенности). И там же есть окошко для указания расширений (), .so? .dll?), загрузка которых инициируется при первом же подключении.

Вызывается панель
Ctrl+R
odbcad32

Насчет мыслей об Excel/Calc+SQLite - пока еще формулирую. Но вводные такие:

1) Анализировать и визуализировать в 8 из 10 случаев приходится что-то принципиально новое, и в 80% случаев используют для этого Excel/Calc

2) В 6 из 10 случаев объем исходных (или сырых) данных таков, что даже весьма продвинутые формулы Excel/Calc не справляются (сотни тысяч строк, сотни столбцов, нечеткие критерии), и они откровенно тупят (пересчет идет минуты). В то же время конструкции вида

SELECT SUM(SUMMA)*(FIO LIKE '%ИВАНОВ%') работают на таких объемах за секунды даже без индексов. А с индексами (при сравнении) - они просто разрывают Excel/Calc на части. Плюс SQLite делает Excel/Calc безразмерным.

3) SQL задумывался как "язык запросов для менеджеров", но не стал им. Просто было рано, и пока в РФ будут учить GWBASIC в средних школах вместо Python и SQLite - и будет оставаться "рано". Но времена меняются...

RXL, у вас в случае с Excel2003
1) Стоит флаг OEMCP?
2) Сама база в utf-8?
3) Excel с SP1&

RodionD, там упомянуты плагины:

- zipfile extension module
- CSV table extension module
- vitrual table extension module
- impexp extension module
Но доступны исходники и можно, видимо, пересобрать с нужными extensions и даже ICU.\

Про использование RAM-base ничего сказать не могу. По-моему должно работать.