Обработка для быстрого полного пересчета итогов по выбранным регистрам, ускорение достигается за счет предварительной очистки таблиц итогов средствами MS-SQL.
Идея ускорения взята из публикации Зачем в 1С нужно периодически пересчитывать итоги по регистрам?. Смысл в том, что основное время при пересчете итогов тратится платформой на удаление итогов с помощью DELETE. Предварительная очистка итогов с помощью TRUNCATE TABLE существенно ускоряет пересчет итогов.
Подключение к MS-SQL реализовано через ADO. Код открыт.
Функционал
- Настраиваемый список регистров для пересчета.
- Работа в обычном и управляемом режиме.
- В управляемом режиме подключение к MS-SQL может выполняться на клиенте и на сервере.
- При использовании платформы 8.3.1 и выше есть возможность пересчитать итоги регистров сведений, для которых установлен признак "Разрешить итоги".
Требования
- Платформа 8.2 и выше.
- СУБД MS-SQL
- Четкое понимание зачем пересчитывать итоги, и к каким последствиям это может привести.
Установка
Установка не требуется, обработка запускается как внешняя.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
У стандартного метода есть неоспоримый плюс — пересчет идет транзакциями помесячно. И если срубить процесс в середине — ничего страшного не произойдет. И даже отчеты могут работать. А если предварительно делать транкейт, то работа встанет до конца пересчета, а если еще и ошибка произойдет…
Задумка хорошая, но зачем пересчитывать итоги за весь период? Я не думаю, что в предыдущие периоды кто-то активно вносит изменения.
Честно, говоря, я вообще сейчас склоняюсь к тому, что в большинстве случаев для регистрв остатков нужны только Актуальные итоги
(1) нужен транкейт + * даты итогов на 010101. Тогда все будет быстро и корректно с запросами.
PS: пойду напишу статью про оператор truncate, чтобы таких обработок не создавали. ((( Неужели гугл и ssms более страшен, чем чужие обработки??
(2)
это как??? )))
Монопольный доступ нужен или нет?
(5) Нет.
SQL 2014. Аутентификация SQL. Запуская на сервере. В SQL спокойно захожу, а обработка пишет недоступен.
{ВнешняяОбработка.УскоренныйПолныйПересчетИтоговРегистров.Форма.ФормаУправляемая.Форма(219)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
Хотя я разобрался. Из имени сервера надо удалить номер порта 1С.
(1) Стал юзать эту обработку именно из-за «неоспоримых плюсов» стандартного метода. Дело в том, что для стандартного пересчета надо именно наглухо остановить работу, так как он делается монопольно, а у нас весовая работает круглосуточно. А если срубить этот процесс в середине — наступит полная и беспросветная жопа. Оборотки просто перестают работать. Наглухо зависают и все. Банда юзеров кричит караул.
Колбасит, профайлер циклично показывает begin, select, insert, truncate, commit. Все ок, при этом проц нагружает порядочно. Даже параллельно работать можно в базе. Чего не хватает обработке — так это прогресс бар прикрутить бы.
Обработкой пришлось воспользоваться, так как стандартный метод расчета итогов через предприятие зависал намертво и висел в таком виде до 8 часов, потом я просто убивал это дело. В конфигураторе тестирование-исправление-пересчет вел себя точно так же.
Обработка сделала все за 2 часа.
Респект и плюс в карму.
(8) я имею ввиду не стандартный диалог из «все функции», а выполнение метода РегистрНакопленияМенеджер.<Имя регистра накопления>.ПересчитатьИтогиЗаПериод() и ~.ПересчитатьТекущиеИтоги() которые выполняются относительно быстро (если делать в цикле по месяцам), не требуют монопольного доступа и не блокируют базу (если не трогать итоги за обновляемый период, т.е. оперативную работу вообще никак не затрагивает). Только последний этап — пересчет текущих итогов может сделать небольшую паузу в работе, но как правило эта пауза измеряется максимум в минутах.
(9) Прикрутить прогресс-бар можно. Кроме как, считать количество рассчитанных регистров от общего числа, ничего не могу придумать.
Такой прогресс будет очень примерным.
(11)Вопрос появился. Не по работе обработки, а может было что-то подобное в личном опыте. На копии базы отработала нормально, все пересчитало четко. А вот на рабочей базе не сработала. Зависла и все. В профайлере отслеживал работу — просто в какой то момент перестали поступать запросы. Был последний BatchCompleted и потом все остановилось. Точно так же себя ведет конфигуратор на пересчете итогов и в режиме предприятия тоже. Зависают пересчеты регистра бухгалтерии. Не доводилось с таким сталкиваться? Не знаю на что и думать, на платформу или на скуль. Платформа 8.3.10.2299, скуль 2008R2 10.50.1600.1
(12) Не подскажу.
(13)
Удалось полечить вашей обработкой в два прохода. Сначала удалить итоги, потом пересчитать. Вещь годная. Спасибо.
Добрый день коллеги !
прошу знающих дать совет практический :
Порядок действий при пересчете итого по регистру каков ?
имею ввиду сам код в произвольном алгоритме — а не обработки готовые — предпочитаю все же понимать что делаю
1. отключаем расчет итогов :
Регистр<Имя>.УстановитьИспользованиеТекущихИтогов(Ложь)
2. включаем использование итогов :
Регистр<Имя>.УстановитьИспользованиеТекущихИтогов(Истина)
3.Регистры<Имя>.ПересчитатьИтогиЗаПериод(НачалоМесяца(Дата() )
или же иной порядок ?