Изтриване на данни директно в SQL

Работата по обработката може да бъде разделена на 3 части:

1) Избор на обекти за изтриване и настройка на селекции

2) Формиране на текстове на заявки

3) Изпращане на заявки

Обекти и техните настройки

Можете да изтриете следните обекти:

Директории (+ PM, Подчинени с техните PM, Подчинени на подчинени и т.н.)
Документи (+ Движения, Дневници, Поредици, PM)
Информационни регистри (само за основната таблица)
Регистри за натрупване (само за основната таблица)
Счетоводни регистри (само основна таблица, + Subconto)
Бизнес процеси (+ PM, задачите с техните PM - вложени BP не се вземат предвид)
Задачи (+ PM)

Регистрите за изчисления все още не са включени в този списък, аз вече ще гледам по броя на кандидатите.

Посоченото в скоби също се изтрива заедно с основния обект.

Позволете ми да обясня ситуацията с вложени захранващи блокове, когато изтривам основния: изпълнението на това ми се струва твърде отнемащо за момента и може би ненужно. Анализът на маршрутната карта, за да се определи кой конкретен захранващ блок може да бъде вложен, не е за внушение, тъй като опитът ми говори за използване на напълно нетривиални схеми с отменяне на захранващия блок. Най-лесният начин е да премахнете BP, като вземете предвид реда и правилния избор.

Изборът може да се извърши само от детайлите (основни, стандартни, общи и т.н.), не е възможно до PM. Изборът може да се извърши чрез полета (чрез точка), като броят на нивата не е ограничен. Всяко групиране на условия (И, ИЛИ, НЕ) може да се използва при избора.

Поддържат се следните типове сравнение:

По равно
Не е равно
| Повече ▼
Повече или равно
По-малко
По-малко или равно
Съвпадение модел
Не съвпада с модела
В списъка
Не е в списъка

Други видове сравнения ще се провалят при генериране на заявки. За съжаление не намерих лесен начин да оставя само разрешени видове, хитрият ACS все още замества своя, така че не губих време да пиша собствен селектор.

Ако някой трябва да направи селекции "В група", тогава за това направете група от селекции "ИЛИ" и добавете селекции от типа Parent.Parent.Parent и т.н. Да, тази опция няма да бъде толкова продуктивна, колкото в 1С, и не се занимавах с това твърде много, но въпреки това за тази обработка е точно.

Композитни видове

Струва си да се спрем отделно на композитни видове. Почти всичко, свързано с тях, беше взето предвид при обработката). Основната трудност е обработката на заявки чрез точка, ala Registrar.Date тип. В този случай всичко, което може да съдържа композитният тип, ще бъде свързано към основната таблица (точно както в 1С). Също така се взема предвид, че някои таблици може да нямат окончателния реквизит и те няма да бъдат в крайната заявка: като пример имаме избора на регистратор. атрибут WarehouseSend и тези 2 таблици ще бъдат прикачени към основната.

Можете да филтрирате по стойност UNDEFINED.

Настройки за запазване и зареждане

Всички направени настройки могат да бъдат запазени за по-нататъшна повторна употреба. Това може да бъде полезно за извършване на процедурата за подготовка на база за разработка или за изтриване в няколко основи.

Формиране на заявки

За да получавате заявки, трябва да кликнете върху бутона „Получаване на заявки за база данни“. След това ще бъдат генерирани заявки за всички маркирани обекти въз основа на селекции. Самият текст ще бъде поставен в съответната колона. На този етап не е необходимо да конфигурирате връзката.

Текстът на заявката съдържа:

Декларация на някои променливи, една от които е YearOffset, тъй като по време на формирането изместването все още не е известно, то е затворено.
Части от заявки за изпълнение, разделени от низа --GO. Малко по-късно ще напиша защо.
Цикъл на изпълнение на част от заявката, като се вземе предвид стойността в "Размер на парчетата"

В допълнение към основния обект към текста за изтриване се добавят и зависими (описани по-горе) и редът е точно такъв, че основният обект ще бъде изтрит в самия край.

При изграждане на селекции с използване на дата се взема предвид изместване, равно на 0 и 2000. Празни дати се коригират съответно.

Връзките за елементите за подбор се формират независимо. Като пример има 2 елемента за подбор Parent.Parent и Parent.Parent.Parent, така че в последния текст на заявката ще има 2 връзки Parent.Parent. Да, една връзка е ненужна, но беше по-лесно да направите това. Да се надяваме, че страхотната скула ще оптимизира всичко).

Ако няма селекции, това ще бъде ТРАНСАТАЛНА ТАБЛИЦА. Но тъй като зависимите също се изтриват с обекта и те могат да съдържат не само данните на изтрития, като пример регистърът за натрупване, където може да има няколко регистратора, тогава за тях тази ситуация се взема предвид и ще не TRUNCATE зависимия, а изтриване от типа на обекта.

Ако нещо не ви харесва в заявката, можете да го редактирате, като попаднете в съответното поле.

Примерен текст на заявка:

Текстът на заявката може дори да бъде изпълнен не чрез обработка, а копиран в управлението на студиото и изпълнен там.

Можете да видите само маркираните обекти за генериране/изпълнение на заявки, като щракнете върху бутона със стрелка (до бутона за получаване на заявки). Много е удобно, когато има много от тях и те са разпръснати в различни колекции от метаданни.

Изпълнение на заявки

Преди да изпълните, трябва да конфигурирате връзката, за това трябва да кликнете върху хипервръзката до бутона за изпълнение. Ще се отвори прозорец:

Има и бутон за проверка на връзката.

Също така, преди изпълнението, можете да промените реда на изтриване на обекти. Той се намира в последната колона и е зададен само за колекции. Но можете да зададете за конкретен обект, в противен случай ще се вземе редът на колекцията.

Когато кликнете върху бутона за изпълнение, се извършват следните действия:

Цялото изпълнение се извършва на клиента и може да бъде прекъснато по всяко време.

В края информация за продължителността и броя на изтритите.

За да намалите таблиците на общите стойности на регистрите и да ги актуализирате след почистване, преизчислете общите суми, преструктурирайте и т.н.

Е, свийте основата, за да получите ефекта)

Въпреки че тествах всичко с всичко, не може да има грешки при такава обработка)) ако нещо не работи, както е описано тук, или има грешки - напишете всичко, ще го поправя.

Когато проверявах за част от 100 000 обекта, 700-800MB от регистъра на транзакциите ми беше достатъчен, но разбира се всичко зависи от таблицата.

Също така се приемат всякакви конструктивни предложения за подобряване, разширяване на функционалността. Но веднага ще ви кажа, че няма да извая универсално чудовище.

Сравнение на версиите

v1.2 - добавена информация за броя на изтритите/изтритите, добавени настройки за запазване и зареждане

v1.1 - се отърва от функциите StrFind, StrSplit. Платформата може да се закълне в режим на съвместимост с версия под 8.3.6