gifts2017

Альтернативный контроль помеченных и быстрое удаление средствами SQL

Опубликовал Валерий Федоров (barelpro) в раздел Обработки - Свертка базы

Эта обработка является логическим продолжением статьи "Свертывание объемной базы средствами SQL" http://infostart.ru/public/249429

Обработка анализирует и удаляет помеченные на удаление справочники и документы, а так же документы без движений. Конечная цель - выполнить анализ и удаление ссылочных объектов быстро, незаметно и безопасно при параллельно работающих пользователях и на объемной базе. 

Что послужило поводом для создания собственного решения: 

Типовой механизм платформы "Удаление помеченных объектов" имеет два недостатка: работает очень медленно и требует монопольного режима.

Медленно потому, что: 

1. пытается сделать все и сразу для всех объектов. Хотя есть возможность ручного выбора объектов, но ты же не будешь как дятел по одному объекту выбирать каждую минуту? 

2. пытается найти и показать все ссылки на объект (хотя справедливости ради надо отметить в упр формах есть режим "Полное удаление" - там на это время не тратится, но опять же сразу для всех объектов) 

Требует монопольного режима потому, что:

1С исходит из самого пессимистичного сценария - во время проверки на удаляемость какой ни будь пользователь может создать ссылку на удаляемый объект, а мы его уже поставили в очередь на удаление и через некоторое время удалили. Монопольный режим полностью исключает вероятность появления битых ссылок. Но как быть в случае работы пользователей с базой в режиме 7*24?

Другое решение - обработка с ИТС УдалениеПомеченныхОбъектов.epf (или DeleteMarkedObjects). Она позволяет анализировать и удалять в разделенном режиме. Но в ней используется все тот же встроенный в платформу метод ТаблицаСсылок = НайтиПоСсылкам(МассивКУдалению). Именно он работает крайне медленно. Даже если переписать обработку и подсовывать ей объекты по одному, она будет искать все ссылки на объект, на чем тратится безумное количество времени. Так же из-за большого временного лага между анализом и непосредственным удалением появляется довольно высокий шанс вклинивания какого ни будь Powered User и генерации битых ссылок. Битые ссылки - явление достаточно неприятное и трудно исправимое. И хотя средства лечения давно найдены (например http://infostart.ru/public/98973/), но зачем нарываться?

Справедливости ради надо отметить одно очень интересное решение "Свертка базы SQL + Альтернативный контроль удаления помеченных" http://infostart.ru/public/139651/. Но тут опять не без ложки дегтя. Оно довольно-таки платное. Кроме того мне показался сценарий автора слишком уж сложным и в итоге негодным для разделенного режима. Да, он сделал быстрый движок для анализа и удаления, быстрее чем в вышеупомянутых решениях, но все равно остается опасно большой временной лаг между анализом и непосредственным удалением, потому что он пытается за один раз удалить все по максимуму, а для этого требуется долгий алгоритм для выявления последовательных или закольцованных цепочек ссылок. 

Я решил максимально ускорить процесс анализа удаляемости. Это можно сделать только за счет упрощения алгоритма. Приносим в жертву качество, получаем выигрыш в скорости и уменьшаем шансы появления битых ссылок. Под низким качеством я понимаю недообследованные до конца и потому оставленные неудаленными объекты. Что происходит в моей обработке: я анализируется последовательно каждый объект, если нахожу хотя бы одну ссылку на него, то перехожу к следующему объекту. Если ссылок не найдено, то сразу удаляю объект, а не накапливаю список для отложенного пакетного удаления. Если есть длинные цепочки последовательных ссылок, то пользователь интерактивно может повторить анализ/удаление несколько раз. Если есть закольцованные цепочки, то мой алгоритм их конечно же не разорвет, но каков процент таких цепочек обычно бывает в общей массе, особенно в массе удаляемых за прошлые периоды документов при свертке?! Окончательную зачистку можно сделать в монопольном доступе типовым механизмом "Удаление помеченных объектов" - он работает быстро при небольшом количестве помеченных.

Как это работает на уровне интерфейса:

1. Если БД на SQL, то на закладке "Настройки SQL" указываем параметры подключения к SQL. Нажимаем кнопку "Проверить подключение к SQL". Если все ОК то при последующем заполнении таблицы на закладке  "Объекты поиска" будет выдана информация о размерах таблиц:

Вес одной записи, KB
Total table size, KB
Index size, KB
Data size, KB
Unused space, KB

2. На закладке "Настройки SQL" выбираем способ удаления: средствами 1С или SQL. Понятное дело, если ваша база файловая, то вариант один. Если база на SQL, и у вас нет предрассудков против использования не-1С-методов, выбирайте второй вариант. При этом скорость удаления будет существенно выше засчет сокращения накладных расходов, связанных с работой сервера 1С и вызовом предопределенных процедур в модуле удаляемого объекта.
Для режима "Удалять средствами SQL" можно включить режим "Записывать в журнал регистрации событий". При этом журнал будет заполняться по аналогии с типовым удалением средствами 1С, только в поле "Комметарий" будет пометка "Удалено средствами SQL".

3. На закладке "Объекты поиска" нажимаем кнопку "Заполнить".
В список попадают справочники и документы с ненулевым количеством объектов БД, отсортированные в обратном порядке по колонке "Кол помеченных" (или по колонке "Вес одной записи, KB", если база на SQL)- это чтобы сразу было видно с кого начать анализ/удаление. 
Для документов подсчитывается количество объектов без движений в колонке "Кол без движений". Это могут быть проведенные документы с очищенными движениями как часть кампании по сворачиванию базы.
Если у вас база на SQL и на закладке "Настройки SQL" указаны верные параметры подключения к SQL, то будут заполнены колонки с размерами в килобайтах.
Единственная колонка "Можно удалять" будет заполнена на этапе удаления, который можно запустить в режиме имитации.

4. Устанавливаем галочки в колонке "Пометка". Можно воспользоваться кнопками групповой установки или снятия пометок. Если выделить несколько строк, то действие снятия/пометки будет для этих строк. Если выделена только одна строка, то действие снятие/пометка будет для всего списка.

5. После выбора объектов МД можно переходить к поиску соответствующих объектов БД - кандидатов на анализ и удаление. Для этого нажимаем кнопку "Заполнить" на закладке "Помеченные на удаление" и/или "Документы без движений". На закладке "Документы без движений" можно указать отбор по периоду для документов.

6. На закладке "Схема анализа" нажимаем кнопку "Заполнить". На этом этапе для каждого анализируемого объекта МД готовятся тексты запросов типа "ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ всех таблиц, у которых есть поля со ссылками на этот объект МД".

7. Нажимаем кнопку "Анализ (удаление)". Дальше идет вопрос "Одновременно удалять?". Если ответить НЕТ, то будет выполнена имитация удаления, и в таблице "Объекты поиска" будет заполнена колонка "Можно удалять".

Основные фишки на уровне кода:

1. Для определения наличия хотя бы одной ссылки на удаляемый объект выполняется пакет запросов ко всем таблицам, где есть поля с типом удаляемого объекта, например, вот некоторые примеры запросов:

ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ Документ.АвансовыйОтчет.Прочее КАК Т ГДЕ Т.Субконто1 = &Параметр ИЛИ Т.Субконто2 = &Параметр ИЛИ Т.Субконто3 = &Параметр ИЛИ Т.СубконтоНУ1 = &Параметр ИЛИ Т.СубконтоНУ2 = &Параметр ИЛИ Т.СубконтоНУ3 = &Параметр

...

ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ РегистрНакопления.ВзаиморасчетыСПодотчетнымиЛицами КАК Т ГДЕ Т.ФизЛицо = &Параметр 

...

ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ РегистрБухгалтерии.Хозрасчетный.Субконто КАК Т ГДЕ Т.Значение = &Параметр

...

ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ РегистрБухгалтерии.Хозрасчетный КАК Т ГДЕ Т.ВалютаДт = &Параметр ИЛИ Т.ВалютаКт = &Параметр

Конечно, если поле с условием не проиндексировано, то выполняться такой запрос будет медленно, и чем больше таблица, тем медленнее запрос, потому что SQL в запросе будет тупо перебирать все записи таблицы - выполнять команду Table Scan. Конечно самое лучшее, это на время свертки базы в конфигураторе установить у таких полей признак Индексировать. Если такой возможности нет, то остается только одно - начать удаление объектов МД с самым большим показателем "Вес одной записи", т.к. они будут ссылаться на остальные не такие большие таблицы.

Чтобы определить самые тяжелые запросы, на закладку "Схема анализа" я добавил кнопку "Замерить запросы". По завершению замера будет заполнена колонка "Время запроса". По ней можно понять, каких Индексов не хватает. 

2. При удалении средствами SQL удаляются записи в таблицах:

Основная
ТабличнаяЧасть
ТаблицаИзменений
ЖурналДокументов
Последовательность
РегистрСведений (по ведущему измерению)

Например, так выглядит пакет SQL запросов для удаления одного документа, у которого несколько табличных частей, который участвует в планах обмена и в журналах документов и в последовательностях, а одна из последовательностей участвует в планах обмена, и есть регистр сведений с ведущим измерением, ссылающимся на этот документ:

DELETE FROM _Document430 WHERE _IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10847 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10887 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10899 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10920 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10925 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10943 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Document430_VT10950 WHERE _Document430_IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentChngR10960 WHERE _IDRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentJournal12795 WHERE _DocumentRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentJournal23761 WHERE _DocumentRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentJournal22967 WHERE _DocumentRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentJournal23751 WHERE _DocumentRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _DocumentJournal12946 WHERE _DocumentRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Seq17875 WHERE _RecorderRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Seq17867 WHERE _RecorderRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Seq17869 WHERE _RecorderRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _Seq17864 WHERE _RecorderRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _SeqChngR29764 WHERE _RecorderRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57
DELETE FROM _InfoRg13934 WHERE _Fld13935_RRRef = 0xa6dce0cb4ed5f61711e03b64f2ff7e57

И не забывайте, что при массированном удалении объектов база под SQL не уменьшается, а увеличивается за счет разрастания журнала транзакций (*.ldf). За этим надо следить и периодически сжимать, например командой DBCC SHRINKFILE

3. По ходу испытаний выяснилось, что метод Метаданные.НайтиПоПолномуИмени() очень медленно работает, причем только под 8.2. Под 8.3 видимо его оптимизировали. Но все равно пришлось его переписать по своему - см. Функция МетаданныеНайтиПоПолномуИмени()


В общем кому надо, пользуйтесь! Если будут толковые замечания или предложения, сообщайте - будем совершенствовать обработку совместными усилиями.

Скачать файлы

Наименование Файл Версия Размер
УдалениеОбъектов Barelpro 344
.epf 26,15Kb
28.01.14
344
.epf 26,15Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Сергей Старых (tormozit) 27.01.14 10:37
Зачем делать запрос к таблице ДвиженияССубконто, если ты все равно делаешь запрос к основной таблице регистра бухглатерии? Оптимальнее делать запрос либо только к ДвиженияССубконто либо к двум таблицам: к основной таблице и к таблице Субконто.
2. Валерий Федоров (barelpro) 27.01.14 10:51
(1) tormozit,

согласен, но я умышленно разнес на два запроса.

Объясняю:

Для Субконто использую ДвиженияССубконто. Для измерений, ресурсов и реквизитов - основную таблицу. Так легче потом делать замеры и определять необходимость индексации реквизита.

Например, в УПП в регистре бухгалтерии Международный есть реквизит ПервичныйДокумент - составной по всем видам документов. Но любой документ так же может быть в роли субконто этого регистра. Если буду делать все в одном запросе - усложняю задачу по поиску причины тормозов.

PS. Невнимательно прочитал вопрос. Да, запрос к Субконто более оптимальный, чем к ДвиженияССубконто, исправлю, спасибо!
3. Юрий Гончарук (yukon) 27.01.14 10:57
И не забывайте, что при массированном удалении объектов база под SQL не уменьшается, а увеличивается за счет разрастания журнала транзакций (*.ldf). За этим надо следить и периодически сжимать, например командой DBCC SHRINKFILE


Вот ведь все хорошо пишите. Но это вот зачем писать-то? На сколько увеличат объем журнала транзакций именно ваши "ручные" транзакции? Да ни насколько.

Периодически сжимать журнал транзакций на рабочей базе нельзя, ну только если вы техномазохист и/или у вас НЖМД в "сервере" аж целых 40Гб.
4. Валерий Федоров (barelpro) 27.01.14 11:02
(3) yukon,

вы не поверите, после удаления 50млн записей регистров методом TSQL DELETE база выросла в полтора раза (в моем случае до 150Gb) как раз за счет разрастания журнала транзакций. DELETE пишет себя в журнал транзакций, даже если recovery model = simple.
5. Юрий Гончарук (yukon) 27.01.14 11:39
(4) barelpro,

вы не поверите, после удаления 50млн записей регистров методом TSQL DELETE база выросла в полтора раза


Охотно верю. И как часто вы удаляете 50 млн записей? Неужели ежедневно.

Если действия массовые и разовые, то сжать журнал транзакций разово можно. Но периодически сжимать на рабочей базе нет необходимости.

в моем случае до 150Gb


Если у вас на сервере один жесткий на 320Gb, то да это ПРОБЛЕМА, согласен.
6. Валерий Федоров (barelpro) 27.01.14 17:30
(5) yukon,

так я собственно предлагаю периодически сжимать файл транзакций только при массированных удалениях, особенно если запас дискового пространства не ахти. Рассказать про все случаи разрастания файлов mdf ldf - это совсем другой контекст статьи.

ps. По своему опыту знаю, что урезание файла журнала транзакций можно выполнять при работающих пользователях. Эта операция быстрая и безболезненная. А вот урезание файла с данными (mdf) может быть долгим, т.к. процесс похож на дефрагментацию диска. Файл данных разрастается, например, после реструктуризации базы - попробую объяснить почему: все таблицы пересоздаются и записываются в конец файла mdf, данные из старых таблиц переносятся в новые, старые удаляются, и появляются дырки в начале файла mdf. Как-то так...
7. Юрий Гончарук (yukon) 29.01.14 12:20
По своему опыту знаю, что урезание файла журнала транзакций можно выполнять при работающих пользователях.


Можно, но крайне не нужно.

Эта операция быстрая и безболезненная.


Это не так. Операция далеко не безболезненная.

все таблицы пересоздаются и записываются в конец файла mdf


Это весьма упрощенное и, как следствие, в большинстве случаев, неверное представление. На увеличение размера mdf файла(ов) влияют с десяток факторов. А уж на размещение данных внутри mdf-файла(ов) как бы не сотни.

Внешняя простота работы SQL-сервера, не означает, что внутри все примитивно устроено. Тот факт, что SQL сервер до определенных пределов умеет сам за собой ухаживать, не означает, что можно выполнять любые манипуляции - пока не падает все типа нормально.

В частности, размер ldf файла в модели восстановление simple SQL сервер выбирает именно такой, чтобы обслуживать базу данных при существующей интенсивности работы. Вместо помощи серверу и увеличения размера ldf файла, хотя бы до размера "чуть больше чем надо", вы предлагаете на постоянной(!) основе вставлять серверу палки в колеса, это же "быстро и безболезненно".
8. Валерий Федоров (barelpro) 29.01.14 12:36
(7) yukon,
Юрий, я прямо чувствую, что вы обладаете тайными знаниями, и очень искусно их прячете от общества :)

Дайте пруфлинки, объясните развернуто, чем таким чревато урезание журнала транзакций при подключенных к базе пользователях? Все вам скажут спасибо, если знания будут полезны. Тут атмосфера вполне доверительная.
9. Юрий Гончарук (yukon) 29.01.14 16:10
Юрий, я прямо чувствую, что вы обладаете тайными знаниями, и очень искусно их прячете от общества :)

Хорошо хоть не сакральными.

Начнём с Ab ovo: http://msdn.microsoft.com/ru-ru/library/ms189085(v=sql.105).aspx Усечение журнала транзакций

За исключением тех случаев, когда усечение журнала по каким-то причинам задерживается, оно выполняется автоматически следующим образом.
В простой модели восстановления — после достижения контрольной точки.

Там же схема работы механизма.

http://msdn.microsoft.com/ru-ru/library/ms345414(v=sql.105).aspx Факторы, могущие вызвать задержку усечения журнала

Некоторые из этих причин (длительные транзакции, приостановленный сеанс зеркального отображения базы данных и др.) могут привести к переполнению журнала транзакций.
...
Операции резервного копирования и восстановления данных
Активные длительные транзакции

Из популярных изложений было отличное на sqlcmd.ru. Правда они чего-то закрылись :( , так, что придется смотреть через archive.org

Первая часть: http://web.archive.org/web/20120416065146/http://www.sqlcmd.ru/trans_log_internals-part01.html Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер. Часть 1/12

Последняя с выводами:http://web.archive.org/web/20120418002619/http://www.sqlcmd.ru/trans_log_internals-part12.html Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер. Часть 12/12.

Чего не следует делать с журналом транзакций никогда в жизни ни при каких обстоятельствах.
...
* сжимать (SHRINKFILE) лог. Да, в отличии от предыдущих пунктов нельзя сказать что это — «категорическое нет», но все же «почти всегда нет»;
* сжимать (SHRINKFILE) лог на регулярной основе, по расписанию. А вот это — необсуждаемый, совершенно полный и законченный бред. Даже продуманное и обоснованное однократное сжатие лога следует рассматривать как ситуацию чрезвычайную и как попытку предотвратить надвигающуюся катастрофу. Делая же это по расписанию вы признаете, что не прочь поработать «пожарником» на постоянной основе, вместо того что бы один раз тщательно потушить все «очаги возгорания» имеющиеся во вверенной вашим заботам системе.


Пропажу обнаружил вот прямо сейчас. Надо озаботиться сохранением в нормальном виде.
10. Валерий Федоров (barelpro) 29.01.14 17:09
(9) yukon,

вот, уже лучше, осталось только чтобы ссылки открывались :)
11. Юрий Гончарук (yukon) 29.01.14 17:15
(10) barelpro,

По клику не открываются - какой-то набор букв вываливает :( а copy-paste работает. Мистика :)
12. Валерий Федоров (barelpro) 29.01.14 18:30
(11) yukon,

прочитал, но так и не нашел ответа на свой вопрос: если у нас объемная 1С-база, с ежедневным полным бэкапом и включенным recovery mode = simple, и мы провели массированное удаление с помощью команды T-SQL DELETE, и получили распухший журнал транзакций, соизмеримый с размером файла данных, и видим, что свободное файловое пространство на исходе, и спинным мозгом чувствуем, что в любой момент наступит коллапс всей базы, что же все-таки КОНКРЕТНО нам мешает в этом случае сделать усечение файла журнала транзакций?
13. Юрий Гончарук (yukon) 30.01.14 10:18
(12) barelpro,

прочитал


0_0 за час? Там только чтения страниц 30 А4. Минимум на весь день, а с практикой так и на все 3-4 дня.

и видим, что свободное файловое пространство на исходе


Это как так? 150 гигов для современных дисков это не очень внушительный объем. Даже для серверных версий дисков. Заложите в бюджет расширение дискового пространства.

Само по себе такое событие "свободное файловое пространство на исходе, и спинным мозгом чувствуем, что в любой момент наступит коллапс всей базы" уже ЧП. Говорит о недостаточном уровне планирования выполняемых работ. Вы ведь предварительно на тестовом стенде прогоняли столь массивную операцию? И что, на тестовом стенде журнал транзакций не вырос до столь внушительных размеров?

все-таки КОНКРЕТНО нам мешает в этом случае сделать усечение файла журнала транзакций


Конкретно, разово ничего не мешает. Но это далеко не простая и безболезненная процедура. Если уж прям нужно то сделайте ее во время наименьшей загрузки базы. Еще лучше - в "монопольном" режиме. При этом размер усеченного файла оставьте достаточно большим, для обслуживания нормальной рабочей интенсивности работ.

В нормальном режиме эксплуатации SQL сервер самостоятельно производит усечение журнала по мере необходимости.
14. Александр Зубцов (iov) 30.01.14 14:36
(9)(10)(11)
архив zip Сохранил в одном архиве для истории.
15. Валерий Федоров (barelpro) 30.01.14 15:13
(13) yukon,

теперь понял, спасибо за совет! А вы не хотите по этому поводу написать статью на ИС с конкретными рекомендациями для 1С-внедренцев - как правильно настраивать журнал транзакций и почему, чтобы уберечь от возможных негативных последствий?

PS. Для меня, как для внешнего подрядчика обычно недоступны все IT-ресурсы заказчика. Чаще всего они выделяются по мере необходимости - нарезаются виртуальные машины с определенными параметрами. Поэтому на тестовых базах такое часто случается - недостаток дискового пространства. Эту ситуацию я и описал выше.
16. Юрий Гончарук (yukon) 30.01.14 18:30
(14)

Спасибо.

(15) barelpro,

как правильно настраивать журнал транзакций


Ну вы и задачки ставите. "Правильно" - это к SQL DBA, а "на пальцах" могу попробовать.
17. Павел Заяш (Pavl0) 28.02.14 12:38
Маленький баг есть. Получить его сложно. Если в конфигурации количество регистров > 255 то на базе MS SQL упадет при заполнении объектов поиска. У меня такая ситуация на УПП+Appius на документе КорректировкаЗаписейРегистров.
Просто повесил проверку на количество таблиц.
18. Андрей Журавлев (Wrols) 29.04.14 19:36
Почему-то в моем случае сразу не получилось запросто использовать...

В базе все документы за сворачиваемый период уже помечены на удаление.

Пытался сделать удаление одного вида документа.
При заполнении таблица "Документы без движений" - пустая, т.к. при ее заполнении анализируются документы не помеченные на удаление.

В процедуре "АнализОднойИзТаблиц" в строке модуля 739 под комментом "еще раз проверим отсутствие движений" выполняется запрос на наличие движений у объекта с условием "НЕ ТекДокумент.ПометкаУдаления".
При этом результат запроса всегда пустой и удаление не происходит.

К слову, в выражении "ТекстЗапроса_БезДвижений" тоже содержится условие на "НЕ ТекДокумент.ПометкаУдаления".
igor.ofitserov; pit201201; Збянтэжаны Саўка; +3 Ответить 1
19. Timur (timm00) 01.06.14 09:23
Это все потому что данный запрос относится только к таблице документов без движений. А автор как-то забыл поставить условие. После правки данного блока вроде все нормально.
Збянтэжаны Саўка; +1 Ответить 1
20. berator37 (berator37) 31.08.14 08:59
Можно на почту Альтернативный контроль помеченных и быстрое удаление средствами SQL berator37@mail.ru . Заранее спасибо
21. Саўка Збянтэжаны (Збянтэжаны Саўка) 20.11.14 14:18
(19) timm00, (18) Wrols,
насколько я понял то там ошибка не в запросе, а в условии после него:
вместо условия
Если Запрос.Выполнить().Выбрать().Количество() = 0 Тогда
нужно
Если Запрос.Выполнить().Выбрать().Количество() > 0 Тогда

т.е. если есть движения, то нельзя удалять

//еще раз проверим отсутствие движений
Если Строка.ТипМД = "Документ" Тогда

  Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 1 1
    |"
    + НайденныеСтроки[0].ТекстЗапроса_БезДвижений
    + "
    |И ТекДокумент.Ссылка = &Параметр
    |И НЕ ТекДокумент.ПометкаУдаления
    |";
					
  //Если Запрос.Выполнить().Выбрать().Количество() = 0 Тогда
  Если Запрос.Выполнить().Выбрать().Количество() > 0 Тогда
    Строка.МожноУдалять = Ложь;
    Прервать;
  КонецЕсли;

КонецЕсли;
...Показать Скрыть
pit201201; +1 Ответить
22. Саўка Збянтэжаны (Збянтэжаны Саўка) 20.11.14 15:11
глюк какой-то?, не могу изменить адресат поста, ошибся и ответил 20-му
(18) Wrols, (19) timm00,
мой предыдущий пост предназначался вам
23. Николай Зевеке (zekrus) 20.01.15 11:15
Добрый день!
Пытаюсь в УТ 11.0 почистить справочник "Контрагенты".
{Форма.Форма.Форма(539)}: Поле объекта не обнаружено (ОбщийРеквизит)
МдРез = Метаданные[ИмяПоля];
24. Dmitry Bas (b-dm) 28.01.15 12:38
А можно ли как то удалить документы за определенный период ?
25. Алексей Голосеев (Aleksey81) 05.04.15 19:23
barelpro, вы очень душевно поработали. Восхищает, что обработка (субъективно) раз в 50 быстрее удаляет данные и при этом позволяет другим пользователям полноценно работать с базой (в том числе запись и проведение документов. Спасибо.
Однако есть и просьба устранить две странные ошибки.
1) Заменить процедуру ЗначениеНеЗаполнено на сам знаете что....
2) Возможно я не прав, но.... у похоже в коде процедуры АнализОднойИзТаблиц
Понадобилось заменить
						
Строка.МожноУдалять = Ложь;				
//Алексей
//Возврат; неправильная команда
Продолжить;
...Показать Скрыть

Потому как ваша обработка останавливает любую активность, как только находит строку, которую удалять нельзя.
Поправьте меня, если я не прав.
26. Дмитрий Ивакин (pit201201) 29.07.15 09:06
(23) zekrus,
В своей версии обработки я добавил
СпЗамен.Вставить("ОбщийРеквизит", "ОбщиеРеквизиты");
последней строчкой. Вроде взлетело.
ElektronHM; +1 Ответить
27. Дмитрий Ивакин (pit201201) 29.07.15 09:11
Хорошая обработка! Даже не смотря на некоторые, выше отмеченные ошибки.
Есть предложение добавить опцию "отложенное удаление", при котором скрипт не выполняется, а сохраняется в текстовый файл.
28. Дмитрий Ивакин (pit201201) 29.07.15 10:14
Очень не хватает функции "Разорвать циклическую ссылку" .
А то есть два документа СчетФактураВыданный (реквизит ДокументОснование) и ОказаниеУслуг(реквизит СчетФактура) оба помечены на удаление и ссылаются друг на друга.
29. Дмитрий Ивакин (pit201201) 29.07.15 10:35
Чтобы удалить документы, ссылающиеся друг на друга добавил строки

Если (Найти(ИмяТаблицыВЗапросе,"Документ.")>0) Тогда 
    НоваяСтрока.ТекстЗапроса = НоваяСтрока.ТекстЗапроса + " И НЕ Т.Ссылка.ПометкаУдаления";
КонецЕсли;

в процедуру СоздатьЗапросВСхемеАнализа

Очень хочется услышать мнение автора обработки на этот счет.
30. Евгений Цыбань (Tciban) 30.09.15 10:02
(29) pit201201, А где это добавить, поточнее можно?
31. Dmitry Bas (b-dm) 18.10.16 18:03
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа