Uzhast писал(а) 18. Декабря 2006 :: 19:26:

Известно какие: фантомы, грязное чтение и неповторимое чтение (не помню как оно по-русски, nonrepeatable).
А как провайдер себя ведет, если параллельно удаляют? Это должно быть актуально для таблиц регистров.

spock писал(а) 18. Декабря 2006 :: 19:31:

Эти проблемы, ИМХО, гораздо актуальнее для СКЛ, чем для ДБФ. Помню, 1С еще специальное разъяснение давала про отличия работы транзакций в скуле и ДБФ. Мол, что в скуле изменения в транзакции видны другим пользователям, а в ДБФ не видны. Собственно, в этом легко убедиться, если вставить "Предупреждение" в конец модуля проведения расходной накладной. Пока висит предупреждение, прямой запрос не видит никаких изменений в БД. Как только жмешь "ОК", сразу становится видно.

Что касается грязного чтения, то точно таким же образом (читая заблокированные таблицы) работает сама 1С и никого это особо не пугает.

При проведении документов проблем вообще нет, т.к. все равно в этот момент никто не может проводить документы. (Хотя, если "правильно" написать модуль проведения, то и здесь можно создать проблемы)

Момент прямого запроса и параллельного удаления, к сожалению, поймать не могу. Удаление движений при проведении происходит крайне быстро. И как совместить эти моменты для теста, я пока не придумал.

Uzhast писал(а) 18. Декабря 2006 :: 19:08:


А не найдено ли подобное решение для монопольного режима? 

Да, по поводу результатов теста. ИМХО, в случае прямого запроса в модуле документа, такое поведение проблем не вызовет. Сложности только с отчетами, но, учитывая то, что 1С ведет себя точно так же, ИМХО, можно смириться 

sedmin писал(а) 18. Декабря 2006 :: 21:24:

Тут сложность в том, чтобы монопольный режим остался монопольным. Т.е. чтобы никто другой не мог модифицировать БД в монопольном режиме. А пропатчим, а в результате монопольный режим превратится в обычный сетевой (то-то 1С обрадуется, когда этот патч сработает и для локальных версий ). Вообще, действительно можно попробовать. Например, чтобы файлы открывались не в полностью эксклюзивном режиме, а в режиме запрета записи для других. Тогда другие 1С будут отваливаться при попытке открытия базы, а простое чтение из БД будет работать.

Правда, при этом может усложниться использование прямых запросов. Обычно соединение устанавливают в режиме "ReadWrite". А тут придется учитывать, что запись не доступна, поэтому придется, например, думать, что делать с временными таблицами.

Uzhast писал(а) 18. Декабря 2006 :: 21:42:

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

Но вообще, это жуткая, жуткая утопичная идея

Цитата:


Оно может и так, но до чего идея заманчивая

DmitrO писал(а) 19. Декабря 2006 :: 05:53:

Да, по ИТЗ сделать подобное можно.
А вот по ТЗ как? что-то не пойму, объясни подробнее.
Все-таки ТЗ ведь встроенный объект 1С и мы не можем добавить к нему методы С++, необходимые для того, чтобы он мог выступать в качестве провайдера ТП.