Ситуация:
Имеем регистр бухгалтерии, Хозрасчетный.
Сегодня 13 октября, в базе постоянно вводятся новые документы текущей датой. Итоги по регистру рассчитаны по 30.09.2018.

Нам надо прочитать запросом остатки на 02.10.2018 00:00:00 (на начало секунды). Например, по счету 43, не суть важно.
Используем запрос, по виртуальной таблице остатков:

"РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, ..."

Остатки выбираются то правильные, то неправильные.
Похоже ловится ситуация, когда вводится документ от 13.10.2018, и запись в регистре уже есть, а в таблице итогов актуальный итог еще не обновлен.
То есть виртуальная таблица остатков читает неактуальное состояние таблицы итогов и вычитает корректные сформированные записи с 02.10.2018 по 3999 год, получается неправильный остаток на 02.10.2018. Правильно я рассуждаю?
Выполнение запроса в транзакции не помогает. Похоже надо как-то блокировать. Как именно?

Традиционно уже приходится напоминать топикстартерам, что без включения в описание проблемы версии конфигурации и платформы, невозможно рассчитывать на адекватные и соответствующие проблеме подсказки и рекомендации

(1) Я счел, что это относится к всей платформе 1С:Предприятие 8.
На данный момент 8.3.10.2299, конфигурация УПП.

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

(3) Но когда читаем без транзакции, то можем ведь теоретически поймать состояние, когда запись регистра уже есть, а итоги не обновлены? Блокировки же на такое чтение распространяются?

(4) у тебя в любом случае итоги есть только в одной версии, в твоем описании - это по 30.09.2018 (конец дня)

(4) Нет, не можем. Ибо транзакция это ACID. Или всё записано, или ничего не записано.
Если не колдовать с скулем.

(6) +поясниение
https://ru.wikipedia.org/wiki/ACID

(4) Не можем, Итоги рассчитываются и пишутся в той же транзакции, что и запись движений. Поправьте меня, если это не так.
То что итоги рассчитаны по 30.09.2018 не играет никакой роли, т.к. вы получаете остатки после даты рассчитанных итогов - поэтому 1С:Предприятие будет рассчитывать итог отталкиваясь от Актуальных Итогов по таблице оборотов "назад"

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

Например, остаток на 02.10.2018 у меня 10, а я получаю 11.
Вижу, что есть документ реализации на 1 шт, только что проведенный текущим временем 13.10.2018.
То есть в некорректных итогах было еще 10, запись на -1 уже появилась, я получил остаток 11. Пока только такое объяснение.

(6) Не знаю, к сожалению, что на объекте за сервер и как настроен. Но вариант работы серверный.

(10) Вот и нужно узнать. И настучать в морду лица админам.

(11) Чтоб "стучать морду", надо сначала самому разобраться в теме,  а то неудобно может получиться :)

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

попробуйте пересчитать Актуальные итоги по регистру бухгалтерии и потестировать базу.
Проблема не в способе получения остатков

(14) Итоги недавно пересчитывали. Если бы они были некорректные, то результат получался бы некорректный, но всегда одинаковый, как я понимаю. Тестирование долгое, если быстрее решить не получится, то потом будем делать.

Вот сейчас просто взял ОСВ по счету 43, за 02.10.2018, поформировал несколько раз, один раз поймал другое состояние остатков. Отличия  - на те же величины, что в нескольких только-что проведенных документах от 13.10.2018 (они с разницей в несколько секунд проведены, смотрел в ЖР).

(5) Всегда есть еще "актуальные итоги", которые "на конец времён", записываются с датой 01.11.3999. Если, конечно, по регистру вообще итоги не отключены.

Не может ли быть так, что кто-то перепроводит старый документ (до 02.10)?

(18) Очень вряд ли, сентябрь закрыт, да и такая ерунда наблюдается и на 01.10.2018 00:00:01, то есть как только остатки начинают читаться на с таблицы итогов от 30.09.2018, а от актуальных, так сразу начинают скакать.

Выполнение запроса в транзакции не помогает. "Для изменения" не помогает. Ловлю отклонения, и они как раз совпадают с тем, что идет в только что вводимых документах.

(19) всё, что после 01.10.2018 00:00:01 остатки считаются от актуальных. Где вы нашли, что не от актуальных?

(20) Я с самого начала пишу, что они считаются от актуальных, с вычитанием записей.

(21) ну, значит в коде чего-то начудили, смотрите свой код. И запросы.

Возможнло,кто то отложеннле допроведение велючил,тогда сами виноваты

Еще не забываем,что,если в отчете транзакция не открыта,то при выборе двумя запросами из двух таблиц получаем часто,что из первой таблицы выбрали данные до проведения документа,а из второй после.

может еще и срабатывать граница, а не запрос на дату-время.

(24) Тут прямо на одном запросе и одной таблице проблема.

(26) А если поставить закладку в модуле набора записей по поводу несовпадения период записи с датой регистратора?

(27) Там типовые документы проводятся, и у них движения имеют дату-время документа. Если предположить что они временно датой 01.10.2018 записываются, то я бы видел искажение остатка в другую сторону.

Текст запроса секретный?

(29) Да любой простой запрос по виртуальной таблице остатков или остатков и оборотов, например:

ВЫБРАТЬ
    ХозрасчетныйОстатки.Организация,
    ХозрасчетныйОстатки.Счет КАК Счет,
    ХозрасчетныйОстатки.Субконто1 КАК Субконто1,
    ХозрасчетныйОстатки.Субконто2 КАК Субконто2,
    ХозрасчетныйОстатки.КоличествоОстаток КАК КоличествоОстаток,
    ХозрасчетныйОстатки.СуммаОстаток КАК СуммаОстаток
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, Счет = &Счет, , ) КАК ХозрасчетныйОстатки

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

Например, если сейчас, 14.10.2018 вводятся документы, то остаток на 02.10.2018 не могу получить без вероятной ошибки.

(0)[ не могу получить без вероятной ошибки.]
топик откровенная лажа
вместо того, чтобы разобраться в причинах, а это можно сделать и напрямую на сиквеле и техжурнолом, обсуждается то, что не имеет не имеет повторения ни у кого

RCSI + запрос в транзакции спасет тебя

А так непонятно, чему ты там удивляешься. "Nolock" он и в Африке "Nolock"

(6) "Нет, не можем" // Здрасти, как же по-твоему грязное чтение работает?

(31) >то, что не имеет не имеет повторения ни у кого
На 100% уверен?

(34) Грязное чтение при нормальной транзакции?

(36) О какой транзакции речь?
Он тебя спрашивет в (4) "читаем без транзакции, то можем ведь теоретически поймать состояние"

(37) Да никакой транзакции, Кибер, чего вы полощете языком нёбо?
Документ же проводится так просто, никому ничего не обещает...

(38) да всё тут более прозаично, он ведь берет остатки не на момент документа, а на начало секунды. Тут и без транзакций фигня получится.

(38) Запись в регистр производится в транзакции (при проведении документов).

Читаем остатки запросом без транзакции (как во всех типовых отчетах).
Получаем некорректные остатки из-за того что будущими числами ведется изменение данных в регистре, а остатки рассчитываются от актуальных итогов с вычитанием записей от даты остатков по 01.11.3999. То есть в расчете участвуют постоянно изменяемые записи таблиц.

Хотя пробовал уже и чтение в транзакции.

Один фиг ловится искажение остатков.

(39) В чем проблема с получением остатка на дату-время/ начало-конец секунды?

Короче говоря воспроизвел я эту ситуацию на тестовом стенде (MSSQL 2014, 8.3.10.2580).
Конфигурация с регистром накопления, документом, который пишет много записей в этот регистр, чтобы несколько секунд все выполнялось.
И обработка, которая постоянно пинает запрос по остатку на дату, и как только фиксирует изменение, то выводит искаженный остаток.
В одном сеансе запускаем обработку, в другой проводим - отменяем проведение документа, датой больше чем дата остатка.

Если режим совместимости конфигурации "Версия 8.2.13" или "Версия 8.2.16", то проблема воспроизводится. Как с чтением без транзакции, так и с чтением в транзакции (правда, немного по разному).

Без режима совместимости, или в  режиме совместимости с 8.3 (любом) - проблема не воспроизводится. Что-то значит в 8.3 подвинитили.

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

(43) Да, пробовал, тоже ошибка. Также что автоматические, что управляемые блокировки - без разницы, ошибка ловится.

Вот теперь сижу и думаю о судьбах работающих на конфигурациях УПП, УТ в режиме совместимости с 8.2...

+(43) или управляемый режим блокировок?

(44) в автоматическом режиме c "ДЛЯ ИЗМЕНЕНИЯ" не должно быть ошибки.

В управляемом режиме до чтения остатков неплохо было бы поставить управляемую блокировку.

(45) Хотя стоп, включил автоматические блокировки + "ДЛЯ ИЗМЕНЕНИЯ" - просто возникает блокировка, ты прав.

(47) В упр. режиме попробуй поставить блокировку, тоже будут ожидания, но кривых остатков быть не должно

(38) Хз о чем ты

(40) Что тебя смущает? Вроде Я выше написал рецепт

(40) // Один фиг ловится искажение остатков.

А ведь я не зря запросил версию конфигурации, на которой вашим пользователям хочется видеть остатки.

т.е. с учетом поста (42) становится тем более очевидно.

(51) Не зря, любые детали могут иметь значение.

(50) Я не очень в технологических вопросах силен, поэтому до меня не сразу и не все доходит. На данный момент я понял что в 8.3 (в режиме совместимости с 8.3) у баз данных на MSSQL режим RCSI включен по умолчанию, поэтому там такого эффекта искажения остатков не наблюдается, так как запрос (будь он в транзакции или нет) будет читать старую версию данных, пока транзакция по записи движений и апдейта итогов не закончится. Верно?

(54) Если в конфигурации разрешен упр. режим и в свойствах регистра / регистратора движения пишутся под ним же, то верно.
Но вообще обычно к отчетам такой строгости получения данных не предъявляют, т.к. все равно через секунду после его формирования ситуация с остатками может измениться.
На 8.2 (без версий RCSI) запросы в транзакциях тоже спасают, но будешь ловить ожидание на блокировке.

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

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

Ну и отчеты в 8.2 "из коробки" допускают грязное чтение, т.к. длительность блокирующего чтения (в транзакции) может быть значительной, что повышает вероятность получать более частые блокировки по тайм-ауту, что никому как правило не нужно.
Короче все зависит от конкретного регистра и частоты записи в него (и длительности блокировки при записи). Если ты пишешь, что тебя интересует регистр бухгалтерии, и документы в систему вводятся часто, то вряд ли твоя идея чего-то там блокировать для формирования отчета придется по душе конечному пользователю.