hogik писал(а) 28. Августа 2008 :: 12:19:

Извиняюсь.
Тов. hogik так и не понял.

В Совет Федерации обратились субъекты федерации с требованием о запрещении шовинистской поговорки "незваный гость хуже татарина".

Слушали-постановили.
Впредь говорить "незваный гость лучше татарина".
НЛ, разумеется.

--
Я слишком ленив, чтобы идти регистрироваться на инфостарт.
Не нравится он мне.

Я рад, что твоя разработка не нуждается в моих тестах.
И в принципе, понятно, что мы оба не нуждаемся в информации и опыте собеседника.

Мне просто хотелось по-возможности чем-то помочь, да пообщаться за чашкой водки.
А к тому, что это не всегда удается, я давно уже привык.
Ну что делать, возможности второй сигнальной на заре третьего тысячелетия по-прежнему ограничены.

Независимо от всего этого, я рад, что вот есть ты и вот есть твои разработки.
Которые нужны людям.
Так что по-прежнему: "удачи" и "ю а велкам".

CaBaT писал(а) 04. Сентября 2008 :: 08:19:


Да в-принципе, пока только были проблемы с Begin/End ReadSequnce.

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

Радикальных изменений в интерфейсе компоненты не будет.
Возможны некоторые изменения в общении с поставщиком данных для sqlite, благо в официальных релизах он еще не засветился.

Теперь по поводу ReadSequnce.
Удалось технически сделать возможность указывать для таблиц, применять ли для них ReadSequnce.

Работает это так:
В монопольном режиме ReadSequnce применяется всегда.
В разделенном режиме можно либо не применять ReadSequnce (меньше скорость последовательного чтения), либо применять (тогда таблица пытается заблокироватся на запись, и либо запрос вообще не сможет выполнится - не удалось заблокировать таблицу, либо другие юзеры не смогут писать в таблицу. Плюсы - увеличение скорости чтения).
Я конечно, могу сделать для объекта SQLiteQuery флаг - блокировать таблицы или нет, и тогда он будет влиять на режим применения блокировок ко всем таблицам в запросе. Однако есть и пограничные случаи, например:
Запрос в модуле проведения документа, что-нить читает из регистра и джойнится к справочнику. Очевидно, что в таком запросе в разделенном режиме хотелось бы к регистру применить ReadSequnce (потому что так и так в него никто не может в это время писать, а к таблице справочника не применять ReadSequnce, чтобы не мешать записывать в нее другим юзерам.
То есть надо как-то давать информацию запросу, какие таблицы блокировать, а какие нет.
SQLite не позволяет указывать хинты для таблиц, как MSSQL, типа (nolock).
Могу предложить два варианта:
1. В тексте запроса если хотим, чтобы для таблицы применялась блокировка, имя таблицы указывать с хитрым суффиксом/префиксом - например
select from Справочник_Номенклатура_Locked

2. К объекту запроса добавить метод
Блокировать("Список,Таблиц")

Какой из вариантов реализовать?
Замечу, что по умолчанию в разделенном режиме таблицы будут всегда читаться БЕЗ ReadSequnce, тк ПМСМ небольшое снижение скорости последовательного чтения данных гораздо выгоднее, чем завал системы транзакциями.

И спрошу еще у знатоков - при проведении 1С блокирует таблицы регистров сразу или при первой записи в них? Что-то там помню выясняли при попытках использовать фокс в модулях проведения.

Спасибо за ответ, пошел работать
По поводу блокировок: на мой взгляд, первый вариант более красивый.

orefkov писал(а) 04. Сентября 2008 :: 12:44:

Это более явный вариант - т.е. более очевидный.
Второй может легко выпадать из поля зрения.

Я верил в Александра и поэтому давно переписал много чего на 1sqlite.
Что касается пути по которому идти...
Я согласен с Михаилом что 1-й более очевидный. НО и второй был бы не плох. Но первого было бы достаточно для начала. 

Имел достаточно большой практический опыт по ускорению стандартных запросов 1С при помощи обертки в транзакцию. Даже стандартный запрос при этом ускоряется на порядок (в многопользовательском режиме). До 10 пользователей - все ОК. При >>10 ошибки (Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем) начинают сильно нарастать (видимо из за того, что очередь не успевает рассосаться ). И как правило такие заторы образовывались в пик отгрузок.
Ругань пользователей, жалобы руководству и т.п.
Параметр 10 человек для разных баз конечно может варьироваться.

kms писал(а) 05. Сентября 2008 :: 11:10:

Я и сам не знаю.
Но как показали эксперименты, если в монопольном режиме обернуть запрос в НачатьТранзакцию/ОтменитьТранзакцию - он выполняется быстрее !

kms писал(а) 05. Сентября 2008 :: 11:36:


insert/update/delete скорее всего не будет.
Если только кто-нить не сделает.