Обработка предназначена для ускорения процедуры удаления большого количества объектов.
Не претендую на изобретение велосипеда, но суть примерно такая: запускаем дочерние процессы обработки (сама себя) по количеству ядер процессора.
В итоге в файловом режиме реальный прирост в 2 раза(!) и более. На SQL — 15%
Зачем это нужно? Предположим, у вас база, в которой штук 10 юриков. Учредители, разбегаясь, решили поделить бизнес, и вам надо в базе удалить 9 организаций из 10. Или вы решили свернуть (схлопнуть) базу. В общем, не суть: кто сталкивался с задачей удаления большого количества объектов, тот меня поймёт.
Писалась под 8.3 (только толстый клиент!!!), но на скорую руку добавила поддержку 8.2 (кому надо, код открыт, разберетесь).
При первом запуске обработки нужно её же указать в окошке «Путь к обработке».
Странно, что только в 2 раза. Аналогично делал на SQL — ускорение в количество фоновых процессов. Не точно, но почти. Т.е. на 10 примерно получалось в 7-8 раз.
(1) aspirator23, Ну, если по-чесноку, то статистику не собирала. Субъективно прикинула … к носу — вроде в 2 с небольшим раза быстрее.
На УТ 3.0 для Украины 1С 8.3.4 выдает —
{Форма.Форма.Форма(141)}: Получение элемента по индексу для значения не определено
МассивФорма[Сч-1][ИмяРеквизита] = ЭтотОбъект[ИмяРеквизита];
Как можно побороть?
(3) Sl@v@,
КАк надыбаю УТшку для Украины, гляну. Вы точно уверены, что ваша конфигурация запускается в толстом клиенте?
ДД.
https://yadi.sk/d/T-ypcOGosVFzc
https://yadi.sk/d/F8J9CpDSsVJQ8
Да, в Толстом клиенте обычные формы.
Инсталляция конфигурации —
Cf конфигурации —
(6) Не надо снимать с поддержки. Надо просто в параметрах запуска 1С дописать /RunModeOrdinaryApplication
https://helpf.pro/faq83/view/1735.html
(7) или же в режиме отладки выбрать запуск обычное приложение, но не факт что взлетит.
(7) У него какая-то хитромудрая конфа. У мя не получилось её толкнуть в режиме ранмодеординари
У меня все запускается
(10) Х.з. на тот момент может мне какую другую редакцию конфы пихнули.
Больше года уже прошло…
«Не жнаю, вопчем: само приползло» (с) из анека
Доброе время суток.
У меня тоже запускается в обычном режиме из конфигуратора, но после выполнить выдает старую ошибку —
«{Форма.Форма.Форма(141)}: Получение элемента по индексу для значения не определено
МассивФорма[Сч-1][ИмяРеквизита] = ЭтотОбъект[ИмяРеквизита];
«
(12) Попробуйте заремить 141ю строчку — должно заработать.
Заремил, но не сильно продвинулся в многопоточном удалении —
«Ошибка разделенного доступа к информационной базе»
(14) Давайте с самого начала. Ошибка проявляется только на одной базе или на всех(даже если взять обычную бухню-демку)?
ЗЫ. Уехала поливать огурцы. На след неделе продолжим…
Я только на этой пробовал.
(1)
Имеется ввиду на клиент-серверной архитектуре? На скуле это делается в 1 поток раз в 1000000000 быстрее, чем на 1С.
Тут что-то есть об этом. Если UPDATE поменять на DELETE, а в WHERE прописать _Marked = 1, то удалится только в путь )))
(16) Может конфа базовая? Не дает несколько подключений к базе…
(17)
У вас есть готовый универсальный T-SQL скрипт по непосредственному удалению помеченных на удаление объектов? Была бы очень признательна.
(19)
Т.к. имена в разных базах разные, то универсальный скрипт достаточно проблематично запилить (но можно). Основная проблема — удаление движений в регистрах по удаленным объектам. Ну и 1С может поменять структуру БД, что может привести к неработоспособности скрипта.
Если данные нужно удалить из небольшого количества связанных таблиц, то скрипт написать будет весьма простой задачей. получаете имена таблиц и имена табличных частей. Удаляете данные основной таблицы по признаку _Marked = 1, удаляете табличные части по NULL в соединении с основной таблицей, удаляете данные регистров по NULL в соединении с регистратором. Если регистраторов много, то поле типа «RTRef » содержит номер таблицы, т.е. добавляете условие по этому полю и номеру документа. 10 минут скрипт писать.