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


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 или кнопку "Обновить" в браузере.
Рекламное место пустует