Тема просто выливается из http://www.1cpp.ru/forum/YaBB.pl?num=1192437970, так как это уже не идея, а нечто воплощающееся.
Итак, что же из этого в итоге должно получится.
ВК, которая позволяет из 1С удобно работать с базами SQLite.
Также в dbf версии 1С она будет позволять в базах SQLite обращатся к таблицам 1С через "родные" методы движка 1С (dbeng32.dll), то бишь аналог работы с SQL базами 1С в "родном" соединении. Соответственно, это позволит выполнять запросы к дбф базе и в монопольном режиме.

В этом топике я буду выкладывать новые версии 1sqlite.dll по мере их возникновения.



Версия 1.0.0.4

Может:
- выполнять запросы к базам SQLite в дбф и скл базах 1С.
- отображать справочники 1С в базу SQLite в дбф базах 1С.
- параметризировать запросы SQLite значениями типа строка, число.
- Пытается использовать индексы при работе с таблицами 1С.
  Вот это надо особо протестить.

Не может:
- Типизировать результат выполнения запроса в агрегатные типы 1С.
- Устанавливать текстовые (подставляемые) параметры.

Исправлена ошибка сравнения полей.
Например, при сравнение where descr < 'Б'
попадало все до 'В'

Приложена ертшка, типа для тестирования запросов к базе из SQLite.
Кнопка "Подключаемые справочники" позволяет выбрать, какие справочники
отображать в базу SQLite. Имена таблиц справочников в базе SQLite
равны идентификатору справочника.
Флажок "План выполнения" заставляет SQLite не выполнять запрос, а вернуть
код программы движка VDBE для выполнения запроса.
Подробнее см. на http://www.sqlite.org/vdbe.html


Исправлено 26.10.2007

Версия 1.0.0.5
Пофиксены баги, найденные kms'ом и другими.
Ускорена работа с индексами.
Просьба затестить.
Особенно условия в where, join.
Как реагирует на order by.


29.10.2007

Версия 1.0.0.6
Очередное исправление работы с индексами.
Пофиксены косяки с формированием ключей (не ручаюсь, что все).
Устранен косяк при использовании одной таблицы несколько раз в запросе (join сам с собой).
Убран БОЛЬШОЙ косяк при left join.
Доработки в тестовой обработке.


29.10.2007

Версия 1.0.0.7
Очередное исправление работы с индексами.
В одном месте строки сравнивались регистрозависимо, что могло приводить к неверным результатам.
Добавлено подключение Журнала, документов, регистров (см. код обработки)
Доработки в тестовой обработке.


31.10.2007

Версия 1.0.0.8
Движок SQLite пропатчен на предмет регистронезависимости. Регистронезависимость теперь работает для всех символов, не только для латинских.
Соответственно, LIKE теперь нормально ищет в русских строках.
lower, upper также работают правильно.
Пофиксены мелкие досадные баги.
Строки отдаются движку SQLite и получаются от него через utf8, вместо utf16, что несколько быстрее.
Доработки в тестовой обработке.


01.11.2007

Версия 1.0.0.9
Устранен БАГ при подборе индекса сорировки.
Мелкие улучшения.
Доработки в тестовой обработке.

Саш, а зачем в курилке-то?
Теме прямая дорога в раздел Прямые запросы.
ИМХО и нужно дать ей статус прикрепленной ветки, тема очень полезная.

Федор, перенеси, плиз, ветку!

kiruha писал(а) 20. Октября 2007 :: 07:44:

Да, я планирую сделать "виртуальные" поля в таблицах, представляющие индексы.
То есть каждый составной индекс в таблице будет дополнительным полем в таблице SQLite, представляющей таблицу 1С.
примерно как бы так представляю себе:

select ... from Журнал where Журнал.DATE_TIME_IDDOC >= make_key(:Дата, :Время)

То бишь для операций сравнения с этим виртуальным полем используется составной ключ.
Это позволит более гибко управлять использованием индексов в запросе, а также в дальнейшем создать эффективного поставщика данных табличного поля.

kms писал(а) 20. Октября 2007 :: 09:23:

В силу того, что по виртуальныи таблицам сам SQLite не может строить индексы, полагаю, что отображать в него ТЗ особого смысла не имеет. Гораздо прикольнее будет реализовать выгрузку ТЗ в таблицу SQLite на С++, вызовом одного метода из 1С. А потом SQLite что хочешь с ней будет делать.

kms писал(а) 20. Октября 2007 :: 09:23:

А куда ж без нее?

kms писал(а) 20. Октября 2007 :: 09:23:

GPL естественно. Так как с CVS я в последнее время не работаю, а только с SVN, то наверное, проект захостю на гугле.

orefkov писал(а) 21. Октября 2007 :: 06:36:

Действительно, здорово.
Вопросов больше нет.

Z1 писал(а) 22. Октября 2007 :: 08:52:

Скорее всего да. Только зачем?

orefkov писал(а) 23. Октября 2007 :: 04:51:

Чтобы можно было Работающий запрос 1с выгрузить в sqlite таблицу ( не виртуальная
бд в памяти )
Далее работать с sqlite таблицей аналогично как с ТаблицейЗначений.
Сортировка ,свертка , выборка должны работать быстрее чем с ТЗ.
Может это и промежуточная цель и она будет не нужна, если полностью получиться subj, но как то без индексов на вирт. таблице тоскливо по тестам по одному большому справочнику (64 000 строк) (выборка одной строки гораздо медлеyней ole db).

Вот подумалось...
Если посмотреть с точки зрения пользователя, то было бы очень хорошо, если бы не пришлось переделывать существующие запросы для OLE DB. А то ведь как получается? Для OLE DB:

SELECT * FROM $Справочник.Номенклатура 

Для 1sqlite:

SELECT * FROM Номенклатура 

Нельзя ли сделать так, чтобы в 1sqlite было так, как в OLE DB? В принципе, наверное, можно прогонять запросы через метапарсер и тогда будет получаться что-то в этом роде:

SELECT * FROM sc55 

Т.е., по сути достаточно виртуальные таблицы в SQLite подвешивать к реальным именам таблиц в 1С. Ну и аналогично для реквизитов. У тебя, похоже, реальные имена вылезают, поэтому запросы вида

SELECT sp3433 FROM sc55 

работать не будут...

Конечно, понятно, что некоторые вещи (типа CREATE CURSOR) в SQLite не заработают. Но, наверное, ведь можно как-то сократить объем переделок (а в некоторых случаях количество переделок свести к нулю)...