ТекстЗапроса = "
|DELETE
| _1SUPDTS
|FROM
| _1SUPDTS as U
|INNER JOIN
| #тбУдалять as тбУдалять ON U.OBJID = тбУдалять.OBJID and U.DBSIGN = тбУдалять.DBSIGN";
RS.ВыполнитьИнструкцию(ТекстЗапроса);
при больших объёмах кладёт 1С-ку
Как сделать выполнение его частями?
Думал вот так:
ТекстЗапроса = "
|DELETE TOP 1000
| _1SUPDTS
|FROM
| _1SUPDTS as U
|INNER JOIN
| #тбУдалять as тбУдалять ON U.OBJID = тбУдалять.OBJID and U.DBSIGN = тбУдалять.DBSIGN";
тб = RS.ВыполнитьИнструкцию(ТекстЗапроса);
Пока тб.КоличествоСтрок()<> 0 Цикл
тб = RS.ВыполнитьИнструкцию(ТекстЗапроса);
КонецЦикла;
но не уверен. ВыполнитьИнструкцию при DELETE возвращает таблицу?
При запросе на изменение delete/update/insert ВыполнитьИнструкцию возвращает не таблицу а число - количество обработанных записей.
Т.е. цикл должен быть типа такого:
Пока RS.ВыполнитьИнструкцию(ТекстЗапроса) > 0 Цикл
КонецЦикла
Вообще странно что delete куда-то что-то кладет.
Подозреваю что тут дело не в самом delete а в том как укладывается #тбУдалять.
Если там сотни тысяч строк то как она укладывается. Или она создается запросом.
И еще какие индексы есть у _1SUPDTS, может поможет создание временного индекса по двум полям DBSIGN и OBJID если такого нет.
Быстро глянул что такое эта _1SUPDTS.
И с ней явно неправльно работают.
OBJID это id объекта а он не уникальный!
Для документов он сквозной у всех видов документов а у справочников он уникальный только в пределах самого справочника.
Тобишь один ID может быть у какого то документа и у всех видов справочников одновременно.
Поэтому у таблицы иднекс должен быть по трем полям DBSIGN,TYPEID и OBJID и для оптимального соединения в условии join должны быть все эти 3 поля.
А вашим запросом вы можете грохнуть кучу объектов которые грохать не собирались.
Кaк может человек ожидaть, что его мольбaм о снисхождении ответит тот, кто превыше, когдa сaм он откaзывaет в милосердии тем, кто ниже его? Петр Трубецкой
