Вчера поставил эксперимент такой. Имеем, SQL SERVER 2008 и 1С 8.2.
Автоматические блокировки.

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

На другом раз в 0.5 сек запускаю запросец, типа
ВЫБРАТЬ КОЛИЧЕСТВО() ИЗ Регистр.
В итоге, мне удалось поймать промежуточный момент, когда в результате запроса был результат где то посередине 0 и 100 тыс. записей.

До этого момента, я считал, что промежуточные результаты транзакции не доступны, т.е. запрос бы возвращал бы всегда 0 или 100 тыс после выполнения транзакции

ну добавте
ДЛЯ ИЗМЕНЕНИЯ
иначе возможно грязное чтение

к томуже на количество может и не распрространятся данное ограничение
есть там какая-то оговорка

(1) ДЛЯ ИЗМЕНЕНИЯ в отчете добавить? По-моему эта конструкция используется только для чтения в транзакции.
Да и термин "грязное чтение" применим к чтению незавершенных данных одной транзакции из другой, а я формирую просто отчет.

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

(2)
легко

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

по-любому : чем больше данных - тем больше энторопия.

>ипользование чтения втранзакции приводит к более высокому уровню изоляции

куда выше то на автомат. блокировках...

грязное чтение в 1С бывает только в списках...

(3) В оракле по-другому дело обстоит??

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

>До этого момента, я считал, что промежуточные результаты транзакции не доступны, т.е. запрос бы возвращал бы всегда 0 или 100 тыс после выполнения транзакции

в профайлере смотрели?

кто вообще сказал что это все пишется в рамках одного insert

(7) +1

(7) Да смотрел. Сначала все закидывается во временную таблицу, затем как раз одним insertом из временной перекидывается в таблицу регистра.
Я так понимаю, что если начать читать данные отчетом в этот момент как раз получишь промежуточный результат.

>ипользование чтения втранзакции приводит к более высокому уровню изоляции

степень одна и та же... меняется вид блокировки

>Я так понимаю, что если начать читать данные отчетом в этот момент как раз получишь промежуточный результат.

никуа не верю...

(11) Ну проверьте. Я тоже удивился если честно.

(12) а чо удивляться-то? отчет же не в транзакции...

(13) селект отчета приходит как минимум с REPEATABLE_READ

(14) мнэ... а как система узнаёт что это запрос именно отчета?

(14) а при чем тут REPEATABLE_READ и отчет?

понятие REPEATABLE_READ как я понимаю только для изолированности транзакции, отчет же не транзакция.

(15) других не бывает... есть селекты списков с NOLOCK и "все остальные"

>отчет же не транзакция.

я про запрос который выдергивает данные

(17) опа... а мужики-то не знают...

Так все таки, непонятным остался вопрос.

Отчет, должен выдавать промежуточный результат транзакции или нет??

Мало того что должен, он это и выдает.

Это легко проверить. Берешь документ, который пишет много проводок в одном сеансе запускаешь его проводиться, в другом смотришь проводки и видишь как они появляются по несколько штук.

У нас ситуация поинтересней, мало того что движения появляются постепенно, так еще и итоги обновляются всегда после вставки движений.

Реальный пример из жизни (после которого стало слегка стремновато):
Есть закрытый период например по 29.02.2012 (установлен запрет редактирования, никто в интервале до 01.03.2012 ничего менять не может). Итоги рассчитаны по 31.01.2012. В марте 2012 года пользователи активно колбасят документы (порядка 300 пользователей (т.е. документы вносятся беспрерывно). Формирую отчет, который показывает остатки например по регистру накопления на 29.02.2012 (виртуальная таблица остатков).

Запрос, который транслируется в SQL - это объединение двух запросов - запрос к актуальным итогам (на 3999 год), второй к движениям с 29.02.2012 по 3999 год. Из актуальных итогов вычитаются движения и получаются данные для моего отчета.

В итоге я нажимаю 10 раз "Сформировать" в моем отчете (прошу обратить внимание, что период уже закрыт) и каждый раз вижу разные данные. Т.е. какие-то движения уже записались, а итоги не обновились, а мой отчет уже все подсчитал.

Единственный выход видеть целостные данные - это выполнять запрос в транзакции. В этом случае читаемые данные имеют изоляцию в соответствии с установленным уровнем. Т.е. незакоммиченные транзакции на результат запроса влиять не будут