Поставили задачу чистки уволенных сотрудников за прошлые периоды. В прошлом году на меньшей базе я это уже делал вообще-то. Обработка та же самая, и логика та же самая ибо структура базы не менялась, но возникла проблема на этапе обработки независимых регистров.
Суть проблемы в следующем. Я пытался в своё время оптимизировать работу делая всё запросами по максимуму. Мой запрос тупо пытается в такой ситуации собрать все записи регистра и засунуть их в ТЗ со структурой идентичной регистру дабы потом загрузить из этой ТЗ набор записей независимого регистра. То есть запрос исключает все записи по соответствию условия когда сотрудник в уволенных.
На небольшой по объёме базе это прокатывало, а вот на большой 1С не тупо не хватает памяти.
Можно ли как то мою логику преобразовать в прямой SQL запрос к базе для обработки таблицы?? И как это сделать минимальными трудозатратами. Был бы какой-нибудь update в 1С запросах, так схватил всё что не уволенные и засунув во временную таблицы потом перекинуть в основную. Да update нет и как это всё провернуть для меня не вполне очевидно. :(
Помогайте.

минимальными трудозатратами будет по одному сотруднику. сколько там у вас сотрудников-то?

>Поставили задачу чистки уволенных сотрудников за прошлые периоды.

зачем? перенести в архив и успокоиться нельзя?

Перейти на 64 разрядный сервер 1С:Предприятия и сделать так, чтобы ТЗ обрабатывались не на клиенте.

(1) Уволенных за прошлые периоды 892
(3) Это мысль. Спасибо

> Уволенных за прошлые периоды 892
по одному. не то количество чтобы заморачиваться
не ну можно конечно и 64 разрядного клиента на linux поднять под это дело))

(4) а не проще через набор записей этого вашего регистра с отбором из каждого из уволенных, очищать набор и записывать.
На ночь поставить, за ночь должен отработать?

(2) Коллега вместо того что бы приготовить и провести профилактику в базе валит на то что сильно много сотрудников и база распухла. Типа почистим уволенных она и залетает. Но тут проблема кроется в том что сама коллега не пишет очистку уволенных, а это сваливают на меня. То есть получается проблема на моей стороне, а коллега выглядит белой и пушистой.
(6) Вероятно проще будет. Проблема в том что я особо не разбирался со структурой базы, а писал, по старой памяти, генерацию программно текстов запросов на лету. Вероятно я так же смогу и код отборов генерировать на лету и подсовывать через выполнить.
У меня ищутся ссылки на уволенных. 892 уволенных дают мне примерно миллион тридцать тысяч ссылок на них. Потом производится свёртка ссылок до собственно объекта метаданных и по анализу метаданного генерируется код запросов.

(5) Да у меня как бы и так 64 ех разрядный сервер. Просто ЗУП 2.5 я пиляю ан обычых формах и если я ещё с УФ пробовал клиент серверную работу, то с ОФ такой привычки нет. Запамятовал короче говоря как весь этот код разводить. Пока у меня код обработки не видит серверных методов в модуле обработки. Что-то мне подсказывает что может и не увидеть без какого-нибудь снятия какой-нибудь совместимости. Идея переписать так что бы оно всё работало на стороне сервера идя замечательная. Минимум переделок.

(7) От количества записей - летание оперативной информации не зависит. В чём тогда суть задачи?

(0) Самое простенькое: непосредственное удаление ненужных сотрудников, затем ТИИ с очисткой ссылок. Проверить взлёт - его нет, закрыть тему.

По одному подсовывайте своих сотрудников обработке

(10) Вы не до конца понимаете логику моей обработки. Если в рамках данной логики ей подсовывать по одному сотруднику, то всё станет только хуже. Понятно что если чистить записи по одному сотруднику в независимом регистре, то будет лучше. Однако у меня собирается набор записей которые надо оставить запросом в таблицу значений.
В принципе как указывал (3) взлетело. Единственное что попутно я увидел путь к оптимизации в отказе от таблицы значений. Я сейчас сразу из выборки запроса засовываю в набор записей регистра.

(11) Главное, чтобы вы ее до конца понимали, иначе вообще труба

Сейчас упёрся в проблему в своей логике на ЗУПе. Есть исправленные документы и получается их нельзя провести. Надо будет делать обходной манёвр.