Изтриване на данни директно в 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 таблици ще бъдат прикачени към основната.