Исходя из того, что при включенном параметре базы MSSQL READ_COMMITTED_SNAPSHOT вне транзакций чтение происходит из версий (без грязного чтения), сделал следующее предположение.

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

Вот нашел косвенное подтверждение http://forum-mista.pro/topic.php?id=697431

Кто нибудь еще пробовал?

И без SNAPSHOT чтенние тоже не будет грязным...

(1) даже в авто режиме?

(2) А какая разница, при записи блокируются записи исключительной блокировкой и чтение будет ожидать...

Фактически именно с SNAPSHOT можем получить грязное чтение, так как получив состояние базы до начала транзакции может возникнуть ситуация, когда алгоритм оперирует одними данными, а данные уже изменились (транзакция изменяющая данные завершилась успешно)

(4) Ну это уже искажение смысла понятия "грязное чтение", которое как раз заключается в возможности прочитать данные незафиксированных транзакций.

(3) чтение вне транзакции ожидать не будет

(0) У что, у сервера ms sql есть режим

READ UNCOMMITTED SNAPSHOT ?

У что -> А что

Или речь про 8.3, которая так и читает вне транзакций?

Резюмирую:
1) 8.2 так делать не будет, так как она в любом режиме вне транзакций читает в режиме Read_Uncommited, что запросом, что в списках. Snapshot не поможет.
2) 8.3 так и делает, как сказал автор.

(10) Понятно. Сомнения у меня были именно про работу в автоматическом режиме.

(11) Ты счаст тоже зародил во мне сомнения по поводу авт. режима для 8.3 :-)  Но, скорее всего, так и есть. Но - мало ли! Проверить - стоит!

Проверил на 8.3. Сомнения подтвердились. READ_COMMITTED_SNAPSHOT проверяется 1Ской в режиме "Автоматический и управляемый" и "Управляемый", а в режиме "Автоматический" динамический список отображает незафиксированные изменения.

(13) Да, Read_Uncommited  (with nolock)

Интересно, почему так сделали. Ведь могли бы и для автоматического режима поддержать параметр READ_COMMITTED_SNAPSHOT.

(15) Спроси на семинаре, почему периодический РС при записи накладывает управляемую блокировку по всему диапазону периода.

ну и (15) спроси.

(16) Единственное объяснение, которое придумал - для защиты результатов виртуальных таблиц СрезПоследних и родственных.

(18) + По сути это похоже на блокирование таблицы остатков у остальных типов регистров при их записи, только ее здесь физически нет, но все равно защищается как бы виртуальные таблицы.

(19) Скорее всего оно. Я сам невдуплил.

(15) Потому что декларируется поддержка SQL2000, а в нём нет снапшот-изоляции

(21) Тогда почему же для управляемого режима работает?

(0) ну да, не изменится, был repeateble read/serialized, а стал read commited (точнее его аналогом)

(0) прочитал 5 раз, не понял в чем вопрос. можете перефразировать для особо тупых?

(24) ТС хотел добиться, чтобы в автоматическом режиме чтение вне транзакции осуществлялось в режиме Read Committed Snapshot.
Но 1С как ни крути читает с Read_Uncommited (with nolock)

(25) а, понял, спасибо.

(15)А не проще перевести конфигурацию в "Автоматический и управляемый", ведь Автоматический режим это устаревший?
(19) В 8.3 может быть и реальной таблицей, в новых версиях. Что, конечно, никак не влияет на идею блокировок.
(21) Если бы хотели, то эта функция могла бы включаться если её СУБД поддерживает.

(27) Перевести на режим "Автоматический и управляемый" теперь, когда я знаю такое важное отличие от "Автоматический", конечно здравое решение.

(16) Изменения в 8.3.6

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

В режиме совместимости с версией 8.3.5 поведение не изменилось.

Похоже все таки признали такое поведение не оптимальным.