Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

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

Как правильно и надежно получать остатки по регистрам?
Я
   gae
 
13.10.18 - 10:58
Ситуация:
Имеем регистр бухгалтерии, Хозрасчетный.
Сегодня 13 октября, в базе постоянно вводятся новые документы текущей датой. Итоги по регистру рассчитаны по 30.09.2018.

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

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

Остатки выбираются то правильные, то неправильные.
Похоже ловится ситуация, когда вводится документ от 13.10.2018, и запись в регистре уже есть, а в таблице итогов актуальный итог еще не обновлен.
То есть виртуальная таблица остатков читает неактуальное состояние таблицы итогов и вычитает корректные сформированные записи с 02.10.2018 по 3999 год, получается неправильный остаток на 02.10.2018. Правильно я рассуждаю?
Выполнение запроса в транзакции не помогает. Похоже надо как-то блокировать. Как именно?
 
 
   Фрэнки
 
1 - 13.10.18 - 11:07
Традиционно уже приходится напоминать топикстартерам, что без включения в описание проблемы версии конфигурации и платформы, невозможно рассчитывать на адекватные и соответствующие проблеме подсказки и рекомендации
   gae
 
2 - 13.10.18 - 11:11
(1) Я счел, что это относится к всей платформе 1С:Предприятие 8.
На данный момент 8.3.10.2299, конфигурация УПП.
   Cool_Profi
 
3 - 13.10.18 - 11:12
Проведение документа выполняется в транзакции всегда. И остатки обновляются в той же транзакции. Есть подозрение, что у вас там перемудерно с настройками сервера
   gae
 
4 - 13.10.18 - 11:17
(3) Но когда читаем без транзакции, то можем ведь теоретически поймать состояние, когда запись регистра уже есть, а итоги не обновлены? Блокировки же на такое чтение распространяются?
   Фрэнки
 
5 - 13.10.18 - 11:21
(4) у тебя в любом случае итоги есть только в одной версии, в твоем описании - это по 30.09.2018 (конец дня)
   Cool_Profi
 
6 - 13.10.18 - 11:22
(4) Нет, не можем. Ибо транзакция это ACID. Или всё записано, или ничего не записано.
Если не колдовать с скулем.
   Cool_Profi
 
7 - 13.10.18 - 11:23
(6) +поясниение
https://ru.wikipedia.org/wiki/ACID
   echo77
 
8 - 13.10.18 - 11:23
(4) Не можем, Итоги рассчитываются и пишутся в той же транзакции, что и запись движений. Поправьте меня, если это не так.
То что итоги рассчитаны по 30.09.2018 не играет никакой роли, т.к. вы получаете остатки после даты рассчитанных итогов - поэтому 1С:Предприятие будет рассчитывать итог отталкиваясь от Актуальных Итогов по таблице оборотов "назад"
   gae
 
9 - 13.10.18 - 11:28
(8) То что они в одной транзакции, я не сомневаюсь.
Но я явно вижу отклонение от реальных остатков на значение в записи, по только что проведенному документу.

Например, остаток на 02.10.2018 у меня 10, а я получаю 11.
Вижу, что есть документ реализации на 1 шт, только что проведенный текущим временем 13.10.2018.
То есть в некорректных итогах было еще 10, запись на -1 уже появилась, я получил остаток 11. Пока только такое объяснение.
   gae
 
10 - 13.10.18 - 11:29
(6) Не знаю, к сожалению, что на объекте за сервер и как настроен. Но вариант работы серверный.
 
 Рекламное место пустует
   Cool_Profi
 
11 - 13.10.18 - 11:30
(10) Вот и нужно узнать. И настучать в морду лица админам.
   gae
 
12 - 13.10.18 - 11:31
(11) Чтоб "стучать морду", надо сначала самому разобраться в теме,  а то неудобно может получиться :)
   Фрэнки
 
13 - 13.10.18 - 11:35
(10) тогда нужно еще и версию скуля указывать. Там тоже были какие-то проблемы в прошлых релизах. Не все версии скуля были удачно совсместимы с версиями платформ 1С и там то патчи, то сервис-паки какие-то требовались. Но это надо уточнять. Я помню только, что какие-то проблемы с остатками/итогами/оборотами/сведениями в виртуальных таблицах регистров возникали, но частности мне сейчас на ум не приходят. Гуглить не очень понятно как - инфы мало.
   echo77
 
14 - 13.10.18 - 11:37
попробуйте пересчитать Актуальные итоги по регистру бухгалтерии и потестировать базу.
Проблема не в способе получения остатков
   gae
 
15 - 13.10.18 - 11:44
(14) Итоги недавно пересчитывали. Если бы они были некорректные, то результат получался бы некорректный, но всегда одинаковый, как я понимаю. Тестирование долгое, если быстрее решить не получится, то потом будем делать.
   gae
 
16 - 13.10.18 - 11:59
Вот сейчас просто взял ОСВ по счету 43, за 02.10.2018, поформировал несколько раз, один раз поймал другое состояние остатков. Отличия  - на те же величины, что в нескольких только-что проведенных документах от 13.10.2018 (они с разницей в несколько секунд проведены, смотрел в ЖР).
   gae
 
17 - 13.10.18 - 13:16
(5) Всегда есть еще "актуальные итоги", которые "на конец времён", записываются с датой 01.11.3999. Если, конечно, по регистру вообще итоги не отключены.
   Скиурус
 
18 - 13.10.18 - 13:37
Не может ли быть так, что кто-то перепроводит старый документ (до 02.10)?
   gae
 
19 - 13.10.18 - 13:57
(18) Очень вряд ли, сентябрь закрыт, да и такая ерунда наблюдается и на 01.10.2018 00:00:01, то есть как только остатки начинают читаться на с таблицы итогов от 30.09.2018, а от актуальных, так сразу начинают скакать.

Выполнение запроса в транзакции не помогает. "Для изменения" не помогает. Ловлю отклонения, и они как раз совпадают с тем, что идет в только что вводимых документах.
   hhhh
 
20 - 13.10.18 - 14:50
(19) всё, что после 01.10.2018 00:00:01 остатки считаются от актуальных. Где вы нашли, что не от актуальных?
   gae
 
21 - 13.10.18 - 14:53
(20) Я с самого начала пишу, что они считаются от актуальных, с вычитанием записей.
   hhhh
 
22 - 13.10.18 - 15:02
(21) ну, значит в коде чего-то начудили, смотрите свой код. И запросы.
   Сияющий в темноте
 
23 - 13.10.18 - 16:10
Возможнло,кто то отложеннле допроведение велючил,тогда сами виноваты
   Сияющий в темноте
 
24 - 13.10.18 - 17:12
Еще не забываем,что,если в отчете транзакция не открыта,то при выборе двумя запросами из двух таблиц получаем часто,что из первой таблицы выбрали данные до проведения документа,а из второй после.
   Фрэнки
 
25 - 13.10.18 - 18:18
может еще и срабатывать граница, а не запрос на дату-время.
   gae
 
26 - 13.10.18 - 19:24
(24) Тут прямо на одном запросе и одной таблице проблема.
   dmpl
 
27 - 13.10.18 - 19:54
(26) А если поставить закладку в модуле набора записей по поводу несовпадения период записи с датой регистратора?
   gae
 
28 - 14.10.18 - 06:54
(27) Там типовые документы проводятся, и у них движения имеют дату-время документа. Если предположить что они временно датой 01.10.2018 записываются, то я бы видел искажение остатка в другую сторону.
   МимохожийОднако
 
29 - 14.10.18 - 07:40
Текст запроса секретный?
   gae
 
30 - 14.10.18 - 09:18
(29) Да любой простой запрос по виртуальной таблице остатков или остатков и оборотов, например:

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

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

Например, если сейчас, 14.10.2018 вводятся документы, то остаток на 02.10.2018 не могу получить без вероятной ошибки.
   shuhard
 
31 - 14.10.18 - 10:11
(0)[ не могу получить без вероятной ошибки.]
топик откровенная лажа
вместо того, чтобы разобраться в причинах, а это можно сделать и напрямую на сиквеле и техжурнолом, обсуждается то, что не имеет не имеет повторения ни у кого
   Cyberhawk
 
32 - 14.10.18 - 10:19
RCSI + запрос в транзакции спасет тебя
   Cyberhawk
 
33 - 14.10.18 - 10:20
А так непонятно, чему ты там удивляешься. "Nolock" он и в Африке "Nolock"
 
 
   Cyberhawk
 
34 - 14.10.18 - 10:59
(6) "Нет, не можем" // Здрасти, как же по-твоему грязное чтение работает?
   gae
 
35 - 14.10.18 - 11:09
(31) >то, что не имеет не имеет повторения ни у кого
На 100% уверен?
   Cool_Profi
 
36 - 14.10.18 - 11:11
(34) Грязное чтение при нормальной транзакции?
   Cyberhawk
 
37 - 14.10.18 - 11:40
(36) О какой транзакции речь?
Он тебя спрашивет в (4) "читаем без транзакции, то можем ведь теоретически поймать состояние"
   Cool_Profi
 
38 - 14.10.18 - 12:08
(37) Да никакой транзакции, Кибер, чего вы полощете языком нёбо?
Документ же проводится так просто, никому ничего не обещает...
   hhhh
 
39 - 14.10.18 - 12:12
(38) да всё тут более прозаично, он ведь берет остатки не на момент документа, а на начало секунды. Тут и без транзакций фигня получится.
   gae
 
40 - 14.10.18 - 12:18
(38) Запись в регистр производится в транзакции (при проведении документов).

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

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

Один фиг ловится искажение остатков.
   gae
 
41 - 14.10.18 - 12:25
(39) В чем проблема с получением остатка на дату-время/ начало-конец секунды?
   gae
 
42 - 14.10.18 - 13:06
Короче говоря воспроизвел я эту ситуацию на тестовом стенде (MSSQL 2014, 8.3.10.2580).
Конфигурация с регистром накопления, документом, который пишет много записей в этот регистр, чтобы несколько секунд все выполнялось.
И обработка, которая постоянно пинает запрос по остатку на дату, и как только фиксирует изменение, то выводит искаженный остаток.
В одном сеансе запускаем обработку, в другой проводим - отменяем проведение документа, датой больше чем дата остатка.

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

Без режима совместимости, или в  режиме совместимости с 8.3 (любом) - проблема не воспроизводится. Что-то значит в 8.3 подвинитили.
   Feanor
 
43 - 14.10.18 - 14:12
(42) напиши в запросе на чтение остатков, который выполняется в транзакции в режиме совместимости с 8.2 конструкцию "ДЛЯ ИЗМЕНЕНИЯ", после этого будут выводиться ошибочные остатки?
   gae
 
44 - 14.10.18 - 14:18
(43) Да, пробовал, тоже ошибка. Также что автоматические, что управляемые блокировки - без разницы, ошибка ловится.

Вот теперь сижу и думаю о судьбах работающих на конфигурациях УПП, УТ в режиме совместимости с 8.2...
   Feanor
 
45 - 14.10.18 - 14:18
+(43) или управляемый режим блокировок?
   Feanor
 
46 - 14.10.18 - 14:21
(44) в автоматическом режиме c "ДЛЯ ИЗМЕНЕНИЯ" не должно быть ошибки.

В управляемом режиме до чтения остатков неплохо было бы поставить управляемую блокировку.
   gae
 
47 - 14.10.18 - 14:22
(45) Хотя стоп, включил автоматические блокировки + "ДЛЯ ИЗМЕНЕНИЯ" - просто возникает блокировка, ты прав.
   Feanor
 
48 - 14.10.18 - 14:28
(47) В упр. режиме попробуй поставить блокировку, тоже будут ожидания, но кривых остатков быть не должно
   Cyberhawk
 
49 - 14.10.18 - 16:09
(38) Хз о чем ты
 
 Рекламное место пустует
   Cyberhawk
 
50 - 14.10.18 - 16:10
(40) Что тебя смущает? Вроде Я выше написал рецепт
   Фрэнки
 
51 - 14.10.18 - 16:58
(40)// Один фиг ловится искажение остатков.

А ведь я не зря запросил версию конфигурации, на которой вашим пользователям хочется видеть остатки.
   Фрэнки
 
52 - 14.10.18 - 16:59
т.е. с учетом поста (42) становится тем более очевидно.
   gae
 
53 - 14.10.18 - 17:57
(51) Не зря, любые детали могут иметь значение.
   gae
 
54 - 14.10.18 - 18:36
(50) Я не очень в технологических вопросах силен, поэтому до меня не сразу и не все доходит. На данный момент я понял что в 8.3 (в режиме совместимости с 8.3) у баз данных на MSSQL режим RCSI включен по умолчанию, поэтому там такого эффекта искажения остатков не наблюдается, так как запрос (будь он в транзакции или нет) будет читать старую версию данных, пока транзакция по записи движений и апдейта итогов не закончится. Верно?
   Cyberhawk
 
55 - 14.10.18 - 19:19
(54) Если в конфигурации разрешен упр. режим и в свойствах регистра / регистратора движения пишутся под ним же, то верно.
Но вообще обычно к отчетам такой строгости получения данных не предъявляют, т.к. все равно через секунду после его формирования ситуация с остатками может измениться.
На 8.2 (без версий RCSI) запросы в транзакциях тоже спасают, но будешь ловить ожидание на блокировке.
   gae
 
56 - 14.10.18 - 19:26
(55) >>Но вообще обычно к отчетам такой строгости получения данных не предъявляют, т.к. все равно через секунду после его формирования ситуация с остатками может измениться.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует