Вопрос звучит примерно так: «Чем опасен режим удаления движений «Удалять автоматически?»
Возможно, для кого-то эта статья покажется творчеством капитана очевидность, тем не менее, есть много людей, которые затрудняются ответить на этот вопрос.
А все на самом деле очень просто.
Если у документа установлен режим удаления движений «Удалять автоматически», то при перепроведении этого документа, еще до выполнения процедуры ОбработкаПроведения, движения будут удалены.
Теперь вспомним теорию, что бы удалить данные необходимо наложить X блокировку, а она как известно, держится до конца транзакции.
Получается, что мы блокируем данные в самом начале транзакции, что негативно сказывается на параллельности работы пользователей.
Рассмотрим пример.
Допустим у нас есть некий документ, который делает движения по одному регистру.
При проведении документа сначала выполняются различные сложные вычисления и прочие действия, которые занимают значительное время. В конце процедуры проведения, происходит запись движений, а контроль остатков выполняется уже после записи в модуле набора записей регистра.
Теперь давайте посмотрим, как будет меняться поведение системы, если мы будем использовать различные режимы удаления движений, при перепроведении этого документа.
Оранжевым цветом, закрашены этапы, на которых данные буду блокированы.
На схеме видно, что во втором случае, данные будут заблокированы на гораздо меньшее время, чем в первом. А чем меньше длится блокировка, тем меньше вероятность возникновения проблем при многопользовательской работе.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Да почему бы и нет. Ликбез нужен, без него никак.
В таком случае возникает ламерский вопрос — а зачем вообще нужен режим «Удалять автоматически»?
(2) Потому что этого может требовать логика приложения а так же для обеспечения совместимости. В модуле обработки проведения «Длительных вычислений и прочих действий» может и не быть.
С любовью, всегда ваш Кэп.
(1) peterxx, Нужен, но тема не до конца раскрыта. Была бы раскрыта вопроса (2) не было бы.
Забыт еще один момент — при перезаписи в регистр набора, совпадающего с уже записанным фактической записи не происходит.
То есть при перерпроведении с «удалять автоматически» для какого-нибудь крупного документа сначала запишется пустой набор, потом снова все его движения, а при записи движений «поверх» старых движений есть шанс, что СУБД вообще дергаться не будет.
(5)Я бы сказал, ключевой момент, который вроде бы вытекает из повествования, но не очевиден.
(5)
Так и есть, только это будет действовать не только для крупных документов, а вообще для всех 🙂
Опишите ситуацию при которой СУБД не будет удалять и перезаписывать движения если установлен режим «Удалять автоматически»
На моих тестах удаление происходит всегда.
(6)
Ключевой момент в том, что записи будут блокированы для удаления в самом начале проведения, что не есть хорошо.
(7)
Опишите ситуацию при которой СУБД не будет удалять и перезаписывать движения если установлен режим «Удалять автоматически»
Так я и сравниваю «удалять автоматически» и нет, как и в статье. Если «удалять автоматически» стоит, то очистка идет всегда и обойтись без перезаписи в СУБД шансов нет.
Про большие документы я хотел написать, что у них даже удаление движений долго идет, не то что формирование. Но как-то передумал в процессе написания поста.
Да все что можно удалить нужно закрить от простых и смертеных пользователей чем подальше, а то потом глюков не оберешся,а туту еще чтото удаляется автоматически етот факт заставляет задуматся что в базе на 200 пользователей размером 300 гб кто и чтото автоматически почнет удалять про какую производительность идет речь
(5) Ndochp, вот сейчас на фактических данных проверил:
— провел документ. режим удаления движений «Удалять автоматически при отмене проведения.»
— выбрал в документе ещё раз то же самое значение в реквизите таб. части
— получил при проведении ошибку записи в регистр сведений «запись с такими ключевыми полями…» (ну вы в курсе, про неуникальность)
Так что условия, требуемые для того, чтобы СУБД вообще «не дергалась», несколько строже, чем простое совпадение набора с существующей записью.