vk fb tw rss

Анатомия регистра накопления. Внутреннее устройство и структура хранения.

Двигатель

 

Открываю новую рубрику «Анатомия платформы». Здесь будут публиковаться статьи посвященные внутреннему устройству различных объектов метаданных и некоторых платформенных механизмов.

 

Лучший способ научиться программированию — взять и посмотреть, как это делают другие.

 

Право первой статьи в новой рубрике предоставляю автору Юрию Пермитину.

В статье подробно рассказано об устройстве и структуре хранения регистров, это в свою очередь очень полезно для всех, кто планирует заниматься оптимизацией системы и/или сертифицироваться на 1С:Эксперта
Платформа 1С:Предприятие 8 предоставляет разработчиком конфигураций использовать такой объект как «Регистр накопления». Регистры накопления предназначены для хранения числовых показателей в нескольких разрезах во времени. Общую информацию о возможностях и назначении этих регистров Вы можете узнать на официальном сайте. Если рассматривать его использование в рамках типовых конфигураций от фирмы «1С», то самым наглядным примером будет регистр накопления «Свободные остатки», которых хранит данные об остатках номенклатуры в разрезе складов, качества, характеристик и серий.
Структура регистра "Свободные остатки" в конфигурации "Управление производственным предприятием" вер. 1.3.
Структура регистра «Свободные остатки» в конфигурации
«Управление производственным предприятием» вер. 1.3.
Здесь мы видим, что в таблице регистра хранится количество номенклатуры для каждого отдельного склада, плюс показатели для каждой позиции номенклатуры «разрезаны» по ее качеству, характеристикам и сериям. В итоге, именно регистр накопления позволяет получать доступ к этим данным более оптимальным образом, поскольку структура хранения этого регистра построена таким образом, чтобы конечные SQL-запросы, формируемые платформой, получали необходимый результат за наименьшее время и с приемлемой нагрузкой на СУБД.
Далее в статье проанализируем структуру хранения регистра накопления в базе данных, а также ее изменение при различных настройках регистра.
Все эксперименты будем проводить на тестовой конфигурации с двумя регистрами накопления и двумя документами. Структура метаданных конфигурации Вы можете видеть на следующем скриншоте.
Структура метаданных тестовой конфигурации
Структура метаданных тестовой конфигурации
Приходный ордер, соответственно, делает приход по регистру «ОстаткиНоменклатуры», расходный ордер — расход. В регистр «ДвиженияНоменклатуры» оба документа записывают движения аналогичные регистру «ОстаткиНоменклатуры» за исключением указания вида движения, а также расходный ордер записывает показатель «Количество» с минусом. Уже можно догадаться, что вид регистра «ОстаткиНоменклатуры» — «Остатки», а «ДвиженияНоменклатуры» — «Обороты».
И так, приступим!

ТАБЛИЦЫ И ИХ НАЗНАЧЕНИЕ

Таблица движений

Начнем с того, что бывает два вида регистров накопления: остатки и обороты. Выше было сказано, что в тестовой конфигурации мы создали как раз по регистру каждого вида.
В тестовой конфигурации созданы регистры каждого вида
В тестовой конфигурации созданы регистры каждого вида
Главное отличие этих видов: для регистра накопления с видом «Остатки» ведется учет остатков в разрезе измерений, а также появляется возможность использовать виртуальную таблицу «Остатки». Но как это влияет на структуру хранения регистра в базе?
Для начала отметим тот факт, что вне зависимости от вида регистра в базе данных всегда присутствует таблица движений с именем «AccumRg[n]», где n  — некоторый номер, который присваивается платформой автоматически. В нашей тестовой базе были созданы две таблицы движений регистров накопления:
Таблица движений регистров накопления с видом "Обороты" и "Остатки"
Таблица движений регистров накопления с видом «Обороты» и «Остатки»
Структуры таблиц практически идентичные, за исключением одного поля -«_RecordKind» («ВидДвижения»), которое присутствует только в регистре с видом «Остатки». Для регистра с видом «Обороты» нет смысла указывать вид движения, поскольку приход делается положительным показателем, расход — отрицательным. Различие между таблицами двух регистров накопления могут зависеть от состава измерений, ресурсов и реквизитов в регистре, но в нашем случае состав одинаковый.

Таблицы остатков и оборотов

Теперь поговорим о таблицах, характерных для каждого вида регистра накопления. Если вид регистра накопления установлен как «Остатки», то для него кроме таблицы движений создается таблица остатков с именем «AccumRgT[n]», если же вид регистра «Обороты», то тогда создается таблица «AccumRgTn[n]». Структуры таблиц идентичные, за исключением записываемых в них данных.

Таблица остатков и оборотов, создаваемых для каждого вида регистра накопления
Таблица остатков и оборотов, создаваемых для каждого вида регистра накопления
Состав полей («_Fld») зависит от структуры регистра (измерений, ресурсов, реквизитов). Единственный вопрос, который может возникнуть при рассмотрении этих таблиц — это назначение поля «_Splitter». Тут все достаточно просто. Регистры накопления имеют такой параметр как «Режим разделения итогов».
Включаем разделение итогов для регистра накопления
Включаем разделение итогов для регистра накопления

Его использование позволяет увеличить параллельность работы пользователей при записи движений в регистр накопления. В дальнейшем в режиме 1С:Предприятие можно включить или отключить разделение итогов для регистра. Например, если записываются движения двумя документами, при этом значения в измерениях одинаковые (например, по одной номенклатуре и складу). Тогда эти движения должны повлиять на итоги одних и тех же пар значений «Склад-Номенклатура». Чтобы не возникло ожидание на блокировке, оба документа помещают записи об изменении итогов в таблицу, но с разным значением поля «_Splitter».Касательно данных, записываемых в каждую из таблиц. В таблице остатков («AccumRgT[n]») хранятся лишь записи об остатках. Приведем пошаговый пример изменения записей в этой таблице при проведении документов.1. Движения по регистру «ОстаткиНоменклатуры» отсутствуют.

Нет движений по регистру - нет записей в таблице остатков.
Нет движений по регистру — нет записей в таблице остатков.
Все просто: нет движений по регистру «ОстаткиНоменклатуры» — нет записей в таблице остатков этого регистра.
2. Оприходованы товары «Товар 1» и «Товар 2» на склад «Склад 1» на дату 1.01.2013.
Изменение таблицы остатков при записи движений прихода
Изменение таблицы остатков при записи движений прихода
Вот и первый документ проведен. Мы оприходовали два товара 1 января 2013 года. Поскольку текущая дата 15.06.2013, то платформа создает записи об итоговых остатках для каждого товара и склада на каждый месяц, начиная с месяца оприходования товаров. Так, например, первые две записи с периодом «4013-02-01 00:00:00:000» показывают остатки на конец января 2013 года. Аналогично записываются остатки последующих месяцев до установленной границы рассчитанных итогов регистра (об этом речь пойдет ниже, сейчас граница установлена на 31 мая 2013 года, поэтому последняя итоговая запись по остаткам записана на период «4013-06-01 00:00:00:000»
Также обратите внимание на записи с периодом, где период установлен «5999-11-01 00:00:00:000». Это записи остатков номенклатуры на текущую дату. Хранение этих данных позволяет получать данные по актуальным остаткам с минимальными затратами ресурсов, т.к. не нужно обращаться к записям предыдущих периодов. Использование текущих итогов регистра определяется его настройками как и дата рассчитанных итогов. О настройках регистра мы поговорим ниже.

3. Списание товаров со склада

Пересчет итоговых остатков при выполнении движений по регистру
Пересчет итоговых остатков при выполнении движений по регистру
13 апреля 2013 был сделан расход по товарам «Товар №1», «Товар №2» и «Товар №3». Поскольку движения были сделаны в апреле, то платформа пересчитывает итоговые остатки за весь апрель и май. На скриншоте выше отмечены периоды, по которым производился пересчет итоговых остатков и не производился. Таким образом платформа сохраняет актуальные итоговые остатки как за каждый месяц, так и текущие актуальные остатки. Обратите внимание на записи, где итоговые остатки отмечены зеленым цветом. Эти записи говорят нам, что итоговый остаток равен 0. На самом деле не имеет смысла хранить остаток со значением 0, лучше если записи вообще бы не было (чтобы не создавать лишние записи в таблице). К тому же получение остатков с помощью виртуальной таблицы «Остатки» никогда не возвращает записи, если их остаток равен 0.
Причину, почему платформа сохраняет подобные записи, а не удаляет их, не была мной найдена. Интересно было бы узнать для чего платформа оставляет такие записи. Отмечу лишь, что после пересчета итогов записи с нулевыми значениями удаляются.
4. Последний приход товаров
Движения, влияющие только на текущие остатки (период движений находится позже границы рассчитанных итогов)
Движения, влияющие только на текущие остатки
(период движений находится позже границы
рассчитанных итогов)
Обратите внимание: записей с нулевыми значениями больше не присутствуют в таблице, так как мной был проведен пересчет итогов.
И так, последнее проведение по регистру — приход товаров от 11 июня 2013. Так как движения по регистру сделаны в июне месяца, а граница рассчитанных итогов — это конец мая, то этот приход повлиял лишь на значения текущих остатков.Таким образом, в таблице остатков «AccumRgT[n]» сохраняются и поддерживаются  в актуальном состоянии записи итоговых остатков по месяцам, а также текущий остатков.Таблица оборотов действует по аналогичному принципу, за исключением того факта, что в итогах за месяц хранятся не данные по остаткам, а общий оборот за месяц. Продемонстрируем:
Изменение записей в таблице оборотов "AccumRgTn[n]"
Изменение записей в таблице оборотов «AccumRgTn[n]»
В третьем пункте были записаны движения по приходу товаров в тот же период, что и в пункте 1. Платформа автоматически обновила итоговый оборот за январь 2012 года.Таким образом, в таблице оборотов «AccumRgTn[n]» сохранятся итоговые данные оборотов по месяцам. При этом, если в итоговые остатки делались на дату начала следующего месяца (например, для итоговых остатков за май месяц делается запись на дату 01.06.2013 00:00:00:000), то итоги по обороту платформа записывает на дату начала текущего месяца (например, итоговый оборот за май месяц будет на дату 01.05.2013 00:00:00:000).

ТАБЛИЦЫ НАСТРОЕК ХРАНЕНИЯ ИТОГОВ

Ранее упоминалось, что для регистров накопления есть настройки, которые можно изменять в режиме 1С:Предприятие. Мы говорили об опции «Использовать текущие итоги», а также «Период рассчитанных итогов». Рассмотрим как хранятся эти настройки и дадим их краткое описание.
Настройка регистров накопления в режиме 1С:Предприятие
Настройка регистров накопления в режиме 1С:Предприятие
Начнем с места сохранения этих настроек. Для каждого регистра накопления создается таблица  «AccumRgOpt[n]», имеющая следующую структуру:
Структура таблицы "AccumRgOpt[n]" для хранения настроек регистра накопления
Структура таблицы «AccumRgOpt[n]» для хранения настроек
регистра накопления
Теперь краткое описание некоторых из них:
  1. Уникальный идентификатор регистра накопления — по этому значению платформа определяет к какому именно регистру относятся эти настройки.
  2. Использовать текущие итоги — если флаг включен, то для регистров накопления с видом «Остатки» в таблице хранятся итоги на текущую дату. Выше это уже было продемонстрировано. Записи текущий итогов хранятся на дату «5999-11-01 00:00:00:000».
  3. Использовать итоги — если параметр включен, то платформа будет делать итоговые записи по остаткам или оборотам (в зависимости от вида регистра накопления).
  4. Период рассчитанных итогов — дата, начиная с которой требуется рассчитывать итоги.
  5. Использовать разделение итогов — параметр включает / отключает разделение итоговых записей для улучшения параллельности работы пользователей (ранее упоминалось о назначении поля «Spletter»).
Ранее находил информацию о том, что таблица настроек хранения итогов «AccumRgOpt[n]» создается один раз для всех регистров накопления в конфигурации. Эксперимент показал, что в последних версиях платформы для каждого регистра накопления создается собственная таблица настроек хранения итогов.

ЕЩЕ НЕ ВСЕ

Это не все таблицы, которые создаются в базе данных для регистров накопления. Существует еще ряд таблиц, создание которых зависит от использования агрегатов или включения регистра в планы обмена. Эти таблицы мы не будем рассматривать в рамках текущей статьи.
Отмечу, что все выше написанное справедливо для версии платформы 8.2.17.153. Структура таблиц регистров накопления в других версиях платформы может отличаться. В завершение приведу схему хранения таблиц регистра накопления в базе данных, которую мы рассмотрели выше.
Структура хранения регистра накопления в базе данных (основная таблица + таблица итогов)
Структура хранения регистра накопления
в базе данных (основная таблица + таблица итогов)

 

Друзья, давайте не будем теряться на просторах интернета!  Я предлагаю вам получать на e-mail извещения о публикации новых статей и материалов, таким образом вы всегда будете в курсе самых интересных новостей!

 



Лучшие материалы по теме

Расскажите своим друзьям
Вам ничего не стоит, а им будет интересно
Подпишитесь на обновления
Ваш e-mail: * Ваше имя: *


Обсудить Вконтакте


Обсудить в Facebook

27 комментариев: Анатомия регистра накопления. Внутреннее устройство и структура хранения.

  • Сейчас вот реализую регистры накопления на другом языке (php + MySQL).
    При добавлении /удалении записи в транзакции идет запрос на изменение таблицы срезов (вы их тут называете итогами).
    Можно конечно было триггерами завязать — но не все хостинги разрешают юзать триггеры на MySQL.

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

    По поводу хранения 0 на итогах. 0- это тоже результат и он должен быть зафиксирован хотя бы 1 раз. У меня сделано так — допустим 10 мая мы продали последние 100 шт товара1 на складе 1 -то в актуальной дате у меня будет висеть 0 по данным измерениям, а также на дату 1 июня тоже будет 0. Если в течении июня не было движений по этому товару — то на дату 1 июля с измерениями товар1 и склад1 записи вообще не будет.
    Если же 0 не хранить , то по вашей логике у меня по данным измерениям на срезах должна быть последняя дата 100шт. Допустим этот остаток у меня образовался год назад, и если вот этот 0 на срез 1 июня не зафиксировать — то представьте какой период будет взят по таблице движений если запрос остатков нужно вывести не на текущую дату.

    У меня к вам вот такой вопрос. Вы прекрасно знаете что документ можно провести будущим числом (для примера сегодня 9 декабря, документ я провожу 15 декабря).Соответственно если я завтра (10 декабря) запрошу остатки — то движения по документу от 15 декабря на остаток не повлияют. (Я знаю что для этого можно создавать другой регистр — типа резерв, который при подсчете остатков и учитывается. Но у меня другой случай — записи в регистр попадают при создании документа.)

    Вот тут собственно вопрос — правильно ли я понимаю механизм работы платформы: движения по документу попали в таблицу движений , но в свою очередь они не повлияли на таблицу итогов (срезов) на период 1.01.2015 и на текущие остатки. А когда они собственно повлияют? Напрашивается что как только наступит дата равная дате движения (15 декабря), но тогда их платформа должна была как то пометить и потом сделать корректировку на таблицу срезов.
    Правильны ли мои рассуждения?

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

  • Скажите пожалуйста, получается 1С хранит 0-е итоги для каждого измерения условно 1 раз?
    Т.е. нет по месяцам записей 0 для одного и того же набора измерений, если движение по регистру не было?
    Т.е. здесь хранение адекватно обеспечивает 1С?

    Спасибо!

    • Нулевые записи так же могут быть и по разным месяцам. Например
      Период Склад Товар Остаток
      01.09.14 Основной Стул 0
      01.10.14 Основной Стул 8
      01.11.14 Основной Стул 0

      • Спасибо за ответ! Скорее хотел убедиться, что нет вот такого варианта:

        Период Склад Товар Остаток
        01.09.14 Основной Стул 0
        01.10.14 Основной Стул 0
        01.11.14 Основной Стул 8

        А если окажется подобная картина, то после пересчета итогов будет вот так, верно:
        01.11.14 Основной Стул 8

        • > Скорее хотел убедиться, что нет вот такого варианта:
          Такой вариант возможен только в том случае, если и за сентябрь и за октябрь были движения, но в итоге на остатке остался ноль.

          >А если окажется подобная картина, то после пересчета итогов будет вот так, верно:
          Да, верно.

    • Если изменений по регистру не было, то скорее всего дублирования записи и не будет. По крайней мере у меня так получается (реализовал регистра на php) . Но если движения были в следующем периоде то запись будет — к примеру в след месяце пришло 10 шт товара и ушло 10 шт товара — то запись по остатку будет опять 0

  • Добрый день.
    В книге «Настольная книга эксперта» написано, что параллельно можно записывать в регистр данные, разные по периоду ил и измерениям. Почему не получается записать данные с разным периодом (месяцем)? Режим разделения итогов выключен. Режим блокировок Управляемый. Запись в ТЖ: Regions=AccumRg272.DIMS,Locks=’AccumRg272.DIMS Exclusive Period=[T»20150101000000″:+] Splitter=0 Fld273=259:aad9d28f3309f3af11e4a9446930d437 Fld274=258:aad9d28f3309f3af11e4a9446930d438.

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

      • Блокироваться будет таблица итогов? Тогда подскажите как читать запись в ТЖ: 31:46.433017-14964,TLOCK,4,process=rphost,p:processName=baza1,t:clientID=18,t:applicationName=1CV8,t:computerName=SUM-001170,t:connectID=5,SessionID=6,Usr=Администратор,Regions=AccumRg272.DIMS,Locks=’AccumRg272.DIMS Exclusive Period=[T»20150101000000″:+] Splitter=1 Fld273=259:aad9d28f3309f3af11e4a9446930d437 Fld274=258:aad9d28f3309f3af11e4a9446930d438′,WaitConnections=,Context=’Форма.Записать : Документ.Приходная.ФормаОбъекта
        Документ.Приходная.МодульОбъекта : 13 : Движения.Остатки.Записать();

        Regions=AccumRg272.DIMS — это же таблица движений?

        • Блокироваться будет таблица итогов?

          Блокироваться будет и таблица движений и таблица итогов. Но выше речь шла только про таблицу итогов.

          Тогда подскажите, как читать запись в ТЖ

          Была установлена управляемая исключительная блокировка на регистр AccumRg272.
          Управляемые блокировки работают с объектами, а не таблицами СУБД. Т.е. в данном случае будет заблокирован объект, а на уровне СУБД уже будет идти блокировка и таблицы движений и таблицы итогов. Для таблицы итого событие TLOCK отдельно не пишется. 1С видит просто набор записей регистра, она его и блокирует.
          DIMS это пространство блокировки, т.е. по измерениям.
          При этом блокировка установилась не сразу, а ожидала установки 14964 десятитысячных долей секунды, т.е. 1,4 секунды.
          Разделитель включен, т.к. Splitter=1
          Далее идут поля и значения для блокировки данных.

  • Андрей, подскажите пожалуйста (или направьте может к чему-то/кому-то):
    У нас возникла данная ситуация. Мы производим секционирование своей базы 1С. Реквизит секционирования — «Период» в регистрах и «Дата» в шапках документов. Однако стандартные выборки данных самой 1С в SQL Server (для регистров накопления, например) содержат обычно отбор только по регистратору:
    _AccumRegхххх._RecorderRRef = @P1 AND _AccumRegхххх._RecorderTRef = @P2

    Соответственно, оптимизатор SQL Server не может произвести полноценно Partition Elimination, и генерирует хотя и параллелизируемые, но очень неоптимальные планы запросов, которые охватывают все секции.

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

    Заранее спасибо!

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

      • Спасибо за ответ, Андрей!
        Решаем задачу оптимизации использования дорогого производительного места файлового хранилища + оптимизации обслуживания этих баз (реиндексация, бэкапирование).
        Да, ограничиться таблицей остатков — конечно, вариант, но решающий задачу только частично.
        Файловые группы как раз используем, только по нагрузке на диски видно, что чтение в операциях связанных с набором записей регистра накопления (вроде отмены проведения) — когда есть отбор только по регистратору, чтение идет со всех дисков.
        Если в запросе есть отбор по дате, то все окей.

        • Если использовать файловые группы, и хранить, например высоконагруженные таблице в одной группе (на одних дисках), а менее нагруженные в другой группе (на других дисках), тогда никаких проблем быть не должно. Либо можно высоконагруженные таблицы поделить между разными группами (дисками). А сейчас насколько я понял, вы пытаетесь сделать это разделение внутри таблицы с помощью секционирования по периоду.
          Если сделать секционирование по периоду, а отбор по регистратору, то естественно будет идти обращение к разным дискам.

          • Андрей, спасибо за ответ!
            Дело в том, что наши основные «высоконагруженные таблицы» — это как раз и самые большие таблицы, они и занимают 90% места. Выходит, нам не подходит вариант: просто разделить целиком крупные таблицы на файловые группы, потому как объем ресурсов и времени обслуживания таких таблиц в части реиндексации и бэкапирования неизменно будет расти.

            Как мне видится пока что, два пути: либо менять ГУИД регистраторов, чтобы они сортировались по первым символам, и сделать их числовыми, вроде годов. Либо поднимать какого-либо посредника между сервером 1С и сервером SQL, который будет менять отбор в запросах без отбора по дате…

            • Есть еще 3 вариант.
              Например, можно свернуть базу. Сделать одну оперативную, где будут храниться только актуальные данные, и одну аналитическую базу с архивными данные для отчетов.

  • На странице 50 книги Экперт по тех вопросам есть пример — отрабатывают блокировки как там написано ?

    // Транзакция 1
    НачатьТранзакцию();
    НЗ = РегистрыНакопления.ОстаткиТоваров.СоздатьНаборЗаписей();
    НЗ.Отбор.Регистратор.Установить(ОБъект.Реквизит2);
    НЗ.Прочитать();
    НЗ.Записать();
    ЗафиксироватьТранзакцию();

    // Транзакция 2
    Блокировка = Новый БлокировкаДанных;
    ЭлементБлокировки = Блокировка.Добавить(«РегистрНакопления.ОстаткиТоваров»);
    ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
    Блокировка.Заблокировать();

    Я хочу сказать, что транзакции спокойно выполняются параллельно — почему ?

    • Здесь 2 момента:
      1. Вы не изменяете набор записей в Т1 т.е. сам набор записей никак не модифицируете, следовательно при записи не происходит изменения строк, нет запроса на удаление или обновление, а следовательно и не накладывается X блокировка.
      В Т1 накладывается только управляемая разделяемая блокировка при чтении набора записей.

      2. По идее Т2 должна ожидать Т1 т.к. в Т2 мы блокируем пространство остатков разделяемой блокировкой на чтение, но для того что бы было ожидание в Т2 надо блокировать не просто пространство регистра, а пространство набора записей этого регистра. В вашем случае это ЭлементБлокировки = Блокировка.Добавить(«РегистрНакопления.ОстаткиТоваров.НаборЗаписей»);

      Тогда ожидание будет происходить.
      Ну или сделайте в Т1 изменение набора записей перед самой записью.

  • Добрый день!
    >>1. Вы не изменяете набор записей в Т1 т.е. сам набор записей никак не модифицируете, следовательно при записи не >>происходит изменения строк, нет запроса на удаление или обновление, а следовательно и не накладывается X >>блокировка.
    т.е по сути не модифицированные наборы данных не будут перезаписаны, что аналогично поведению «Записывать модифицированные», хотя выбрано «Записывать выбранные»
    Андрей, подскажите, где это описано.

    • Запись движений при проведении — свойство определяет поведение системы при создании движений во время проведения документа:

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

      — режим Записывать модифицированные (устанавливается при конвертации из версий «1С:Предприятие 8.1» и более ранних) означает, что записаны будут те наборы записей, которые были модифицированы (для них система автоматически установит свойство Записывать в значение Истина).

      Все есть в документации.

  • Добрый день!
    Кто сталкивался с таким:
    1. Есть регистр накопления, использование итогов выключено, текущие итоги выключены.
    2. Автоматический режим блокировок, режим совместимости с 8.2.
    3. Платформа: 8.3.7.2008
    По идее можно провести два документа с абсолютно одинаковыми дынными, т.к. везде присутствует разделитель «Регистратор», но при такой настройке каждый раз при записи в регистр блокируется запись в таблице с настройками этого регистра «…Opt». Там обновляется поле «_MinPeriod». Соответственно параллельной записи не происходит не только по идентичным наборам измерений, в регистр вообще ничего записать не удаётся.

    И ещё вот такое:
    База та же. Регистр тот же. но итоги включены, чтобы была возможность что-нибудь провести параллельно).
    Ставлю точку останова в транзакции. Параллельно провожу документ с другим набором измерений, всё ок. Но при отмене его проведения возникает блокировка на таблице регистра, хотя данные совершенно разные. В profiler нашел запрос, который создаёт временную таблицу и затем вставляет туда строку регистра с условием по ссылке отменяемого документа. НО, запрос выполняется сканированием, в результате чего скан натыкается на заблокированную строку другой транзакции и ждёт. Ради эксперимента в менеджмент студио в кластерном индексе передвинул поле «Регистратор» на первое место, где раньше был «Период». После этого блокировка ушла.

    Я понимаю, что сейчас на автоблокировках уже, почти, никто не работает, просто вот такое наблюдение. Это особенности платформы или я что-то накорячил в своих экспериментах?)

    • 1. Первая ситуация у меня не воспроизводится. Документы параллельно не проводятся, но не потому что таблица настроек блокируется. У меня они не проводятся потому что в таблице движений записи просто рядом расположены. Почему вы сделали вывод что ожидание идет именно на таблице с настройками?
      2. Да бывает такое. Можно считать что это такая фича платформы )).

  • Здравствуйте, Андрей!

    Статья конечно неплохая, но на мой взгляд, для изучения анатомии регистра накопления: лучше всего подходит следующий приём: «Проводить эксперименты средствами 1с, с последующим анализом изменений в таблицах непосредственно в MS SQL».

    PS: в целом, на мой взгляд регистр накопления довольно простой объект, поэтому тут немного скучновато.
    А вот если аналогичная статья появится по регистрам расчёта, вот это будет действительно интересно почитать и опробовать.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *