На всякий случай повторюсь, я не уверен что все работает, собственно поэтому и прошу помощи в тестировании.
И хотя я провел очень много ночей с отладчиком в обнимку, все равно 1С может подкинуть какую-нибудь неожиданность.

А пример с приращиванием единицы мне кажется довольно интересным, попробую обязательно.

Попробую в выходные поставить и потестить . Интересно что получится. Что да как отпишусь.

orefkov писал(а) 20. Июля 2010 :: 18:59:

Но если будет "движение" в теме, можно рассчитывать на твой отклик в плане развития 1sqlite?

orefkov: Видел CodeBase, что и натолкнуло на мысль.

---

Хотел победить конкурирующую запись, но видно не получится.

Использую пример - наращивание значения элемента справочника в цикле, причем, элемент в справочнике единственный (чтобы не заморачиваться с одновременным запуском обработки)

1С действует следующим образом:


блокирует таблицу
выбирает элемент
разблокирует таблицу
...работаем с элементом


далее если необходимо записать результат:

вновь выбирает элемент, но без блокировки
сравнивает с начальной выборкой

если они одинаковы:
блокирует элемент
блокирует изменяемые таблицы
вновь выбирает элемент
сравнивает с начальной выборкой

если они одинаковы - записывает
снимает блокировку с элемента и таблиц

В итоге получается, что в начале мы не знаем, будет записан элемент или нет, и если блокировать как 1С, то возникнут блокировки на чтение (а последовательное чтение, это как раз с чем борюсь).

Можно применять ручное объявление транзакции в узких местах. Только по этому поводу выяснился один нюанс. Транзакцию нужно начинать не в рамках доступа к элементу, а перед выборкой списка элементов ( ВыбратьЭлементы() ). Т.к. первый элемент списка, 1С сразу читает и второй раз не перечитывает (при ПолучитьЭлемент()). Т.ч. при использовании транзакции поэлементно, может возникнуть исключительная ситуация (объект заблокирован) при одновременном обращении к первому в списке.

Но очень хочется победить конкурирующую запись не потеряв в скорости доступа на чтение. Буду думать...

Попробуй протестировать работу 1sqlite и с Александром если надо решить чтобы она работала, вот тогда будет "молоток".

Wirth писал(а) 27. Июля 2010 :: 16:20:

Ну, проблемы были как-раз с разработкой CodeBase.
Дело в том, что в штатном движке 1С с каждой таблицей связан "буфер записи" (запись в смысле record, не write), те при передвижении по таблице данные текущей записи из файла копируются в этот буфер. Для получения значения полей из записи и их изменения в dbeng32.dll существует набор методов Fx_xxx (FX_String, FX_Numeric и тп). Сама 1С работает только через эти методы.
Ну а 1sqlite при работе с 1Сными дбфками не пользуется этими методами, а сразу читает значения полей из этого буфера, напрямую. В разработке CodeBase поменялась внутренняя логика работы с записями, и этот буфер при передвижении по таблице не заполняется. Hogik просто реализовал свои варианты методов FX_xxx, которые возвращают значения полей, но 1sqlite ими не пользуется.
Тут надо либо переделывать 1sqlite на работу с полями через FX_xxx, либо переделывать CodeBase, чтобы заполнялся буфер записи.
Если у тебя работа с буфером записи не изменена, то 1sqlite скорее всего будет работать.

Идеологически зашел в тупик. Нужен совет, а то сам не могу выбрать путь развития разработки.
В общем во-первых. Реализовал два режима работы сервера: - максимальная работа с кешем, соответственно самый быстрый на чтение ; - блокировки записей, нормальная работы с конкурирующей записью (пессимистический режим транзакции).
С одной стороны хочется быстро строить отчеты, с другой стороны хочется чтобы писал без сообщений "объект заблокирован".
Думаю сделать так:
сервер работает в неком среднем режиме, при котором блокировки декларируются, но не используются. И сделать два метода: DirectRead и SafeWrite, к примеру, которые будут временно переводить сервер в режимы быстрого чтения и безопасной записи?
И вторая мысль. Тут начал разбираться с программой Visual FoxPro (как наиболее прямого средства работы с DBF CDX), короче можно интегрировать часть Fox-а  в сервер. Fox поддерживает SQL, но надо думаю, посредством информации в DD переводить наименования объектов в имена таблиц, для удобства. И еще есть поддержка процедур, можно по идее сделать интерфейс исполнения "хранимых процедур" непосредственно на сервере.
Стоит морочиться?

По-поводу FoxPro. Все же это велосипед. Пожалуй переписывать "Прямые запросы" смысла нет. Если только действительно разобраться с блокировками и индексами, да так чтобы еще и триггеры работали. но это как-то пока не реально для меня. Времени много займет.