Доброго времени суток. Готовлюсь к удалению не нужной номенклатуры, тестю разные варианты ;)

Код простой. запросом выбираю номенклатуру.
Далее тестирую удаление ее, с транзакцией и без.

Может я делаю что то не так но разницу я не увидел..
В общем запросом выбрал первые 200. ради теста.

Первый раз удалил эти 200 с транзакцией . Второй раз удалил эти 200 без нее. просто подряд.

В итоге разница между этими двумя разами, было всего в 1.5 секунды, в пользу варианта с транзакцией.

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

Или на такой мелочи как 200 элементов справочника, он ни чего и не покажет?

Чисто логически, с транзакцией должно быть дольше.
200 - семечки.

Объектная модель, ветер серверный...

Если скуль, то можно одним запросом это все грохнуть.

Мне в соседней ветки советовали записывать номенклатуру в транзакциях, партиями.. ибо типо так быстрее.
Я подумал что если удалять номенклатуру то в транзакциях так же должно быть быстрее... но че то я этого пока не увидел
200 поняное дело фигня. просто ради теста запустил

(3) С чего вдруг запись в транзакции должна быть быстрее?

(2) можно, но я не уверен, что я напишу запрос на sql .. у меня там отборы что номенклатура должна быть в иерархии конкретного родителяя, с опредеоенным видом и определенного производителя ну и т.д

(0) >> на такой мелочи как 200 элементов справочника, он ни чего и не покажет?

+1.
Заморачиваться имеет смысл если только количество удаляемых измеряется тысячами.
Да и то придётся поэкспериментировать с подбором правильного размера порции для каждой транзакции.
В типовых в обработчиках обновления конфигурации обычно обрабатывают объекты порциями по 500-1000 элементов/документов/записей.

Если критична скорость, то лучше посмотреть в сторону (2) - запросами СУБД.

(0) Ты совсем удаляешь или помечаешь на удаление?

(0) может ты будешь первый кто реальные тесты проведет

(5) Ну ты сначала айдишники приготовь в 1с или любые другие ключевые поля, а потом
DELETE FROM * WHERE id IN ("1", ..., "100500")

И надеюсь у тебя транзакция то на сервере только да?
Ты же не дергаешь в цикле с клиента сервер надеюсь а?

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

(11) Извини но ты ....

(11) Ветку и коммент в студию)

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

(6) у меня ляма 2 номенклатуры... но ради теста запускать в копии 2 ляма.. что бы потом часами/днями сидеть ждать.. было лень взял 200 )

(13) в 77 реально помогало. А вот по 8 я тестов ни разу не видел

На сколько я понял транзакция прекрасная вещь когда ты грузишь допустим что-то допустим 10 доков, один из них с ошибкой и тебе надо нафиг отменить загрузку предыдущих 9-и ибо они связаны
тогда отменатранзакции тебе нафиг все вернет назад, и все.

Попробовал сейчас на 2000 позиций. ситуация такая же. разница с транзакцией и без.. 1-2 секунды. что не критично.

А тесты с монопольным / не монопольным режимом не делал?

но пока я не вижу как удаление 2000 элементов с транзакцией и без влияют на скорость. сейчас запущу 100к штук.

(17) я в базе 1-н.  думаешь все равно надо установить монопольный режим?

(19) Да

(9) угу, только у справочников, например, есть еще таблица изменений, а у регистров еще таблица итогов, и еще много чего про что вы можете не знать. лицензионная политика 1с придумана не просто так и призывать ее нарушать - не комильфо

(18) Код покажи

И проверь с разным количеством объектов в транзации от 1, 10, 100, 1000, 10000 и т.д.

Если чисто логически рассуждать, то транзакции не должны влиять

(21) ТиИ сверху полирнуть) Делов то
Совсем другое дело тысячи элементов поштучно удалять. Под определение комильфо подходит?

(11) Ветку уже покажи) А то вдруг ты все не так понял)

(23) СУБД приходится дополнительно держать в уме данные о текущей транзакции, которые, подозреваю, могут расти чуть ли не экспоненциально.

(24) тии может выполняться дольше чем простое удаление

(24) нет именно так и советут. Много где видел

(22) Погоди а как ты предлагаешь тестить ??
То есть при 1000 элементов.
Разделить их по 10, потом по 100, потом по 500
И проверить как быстрее будет?

А потом проверить вообще без транзакции ?

Я сейчас все 1000 засунут в транзакцию и грохнул
а второй раз вообще без транзакции. результат одинаковый

(23) Предполагается, что работа с журналом транзакций происходит быстрее, чем с самими таблицами базы.

Мы как бы сначала записываем факт удаления N-записей в промежуточную таблицу, затем, по команде СУБД эти данные скопом записывает в таблицы данных и это быстрее, чем поштучно записывать в базу.

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

Но никто не гарантирует, что нужный прирост скорости вообще произойдет.

(28) я предполагаю что тебе надо менять сферу деятельности
как минимум бросать программирование, особенно на 1С

(27) Так потому что альтернатив нет.

(29) Кем предполагается?
Тесты в студию.

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

(29) ну так чекпойнт не после каждой транзакции вызывается. Скуль сам знает когда нужно

(29) Грязное чтение...
Читает по несколько таблица на один запрос?)

(29) но при чем здесь грязное чтение?

Имхо у ТС основные затраты времени не на удаление а на что то еще.
И транзакция тут не поможет понятно дло.

(36) это с чего вдруг? Что может быть еще?

(36) Короче... очень долго... нет у меня затрат времени. Я засекаю время с начало удаление 1 элемента. И фиксирую время в конце удаления последнего элемента.

Короче с транзакцией и без.. удаление (Именно удаление, не запрос там и т.д.). 20 секуд. что так что так.

то есть 200 элементов. удаляются 20 секуд. то есть 10 элементов в секунду... то есть если их 4 ляма.. то это неделя )))))))))

Код две строки
Для каждого стр из Результат цикл
        
         тт=стр.Ссылка.ПолучитьОбъект();
             тт.Удалить();
    
        КонецЦикла;

(38) не правильно тест делаешь
Нужно допустим 1000 шт и фикс транзакции каждые 200

(40) А потом 1000 штук вообще без транзакции?

Ок сейчас сделаю так.

Но все равно очень долго 200 элементов за 20 секунд. (именно удаление).. на 4 лямах это будет неделя

(38) распареллелить не вариант?

(41) разделяешь на 100500 потоков и вперед

(39) объекты у тебя какого типа?

надеюсь не проведенные документы?

(44) номенклатуру же удаляет

вообще 4 лямов номенклатуры это сильно канешна

(46) Если не используются характеристики, то вполне может быть)

(47) это электроника, всякие лсд, резисторы, конденсаторы, платы реле и т.д и т.п. там 4.5 лямов и все они разные

(48) на ссылочную целостность плевать?

И так тесты

Выбрал 1000

Далее транзакция по 200.

Общее время удаление (именно удаление, без запроса самого и т.д.) 1000 позиций составило - 1 минута 50 секунд

Далее выбрал 1000 позиций и удалил просто без транзакций - 1 минута 51 секунда ))...

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

так что хоть бить эти 1000 на 200, хоть удалять 1000 в транзакции. в одной
хоть удалять 1000 без транзакций вообще разница в среднем 1 секунда, в пользу транзакции... что в обьеме миллионов не критично

(49) как я написал выше.. нет ни каких ссылок. там только номенклатура с артикулом и названиями.  ни где ни когда не использовалась, без картинок и характеристик и цен

(52) так что насчет распараллелить?

(50) Берете массив артикулов для удаления, делите на 7 частей и запускаете 7 сеансов, каждый со своим куском артикулов. В итоге за день все это дело удалите

(54) я не могу взять массив артикулов !
в 30-40% кривой номенклатуры нету артикула воообще

код покажи, может ты начало окончание транзакции не туда влепил.

(55) возьмите гуиды номенклатуры вместо артикулов

то есть я сначала ищу дубли артикулов... это раз
потом ищу дубли в названиях 100% соответсвие.. это два
Потом есть папка(родитель) главная - где я вообще ни чего не проверяю ее тупо надо снести там 300к позиций.

(56) НачатьТранзакцию();
Счетчик = 0;

Для каждого стр из Результат цикл
    Счетчик = Счетчик + 1;
    тт=стр.Ссылка.ПолучитьОбъект();
    тт.Удалить();
    Если Счетчик = 200 Тогда
        ЗафиксироватьТранзакцию();
        НачатьТранзакцию();
        Счетчик = 0;
    КонецЕсли;
                
КонецЦикла;    
     ЗафиксироватьТранзакцию();

Сколько номенклатуры остается может проще грохнуть все а потом нужное записать.

(60) нужной 4 миллиона... не нужной 2 миллиона с чем то... всего 6 лямов

(57) А как я разобью массив гуидов на 10 разных ?
То есть мне надо получить все не нужные мне гуиды номенклатуры.. допустим их 1000
как мне их разбить по 200 и запустить 5 разнрых сеансов ?
сохранить их в 7 разных эксель файлов что ли ?

а 7 разных сеансов с удалением номенклатуры... не будут работать в 7 раз дольше чем 1 сеанс с удаление номенклатуры?

А откуда спешка. может потихоньку грохнуть за несколько ночей частями и не парится. Удалить(0),Удалить(1) попробуй

(62) зачем вам эксель?
Можете создать 7 файликов текстовых Если Счетчик/100000 = Цел(Счетчик/100000) Тогда Пишем файл.
Можно создать 1 файлик и читать его построчно
Для к=НачальнаяСтрока По КонечнаяСтрока Цикл
ТекстДок.ПолучитьСтроку(к);

(64) Так это не несколько ночей...
200 штук номенклатуры . 20 секунд..
считаем. 2.000.000 - это 55 часов. это полные двое суток и это только само удаление (без запросов, отборов там и т.д.) а их больше 2 лямов)

Да и не спешка собственно, а тесты как будет быстрее... одно дело когда это 2 суток, другое дело когда это 7 суток. вот и тестирую

В общем множество есть вариантов реализации

(63) Возьмите 100тыс номенклатуры и протестите. Разбейте на 5 заданий по 20тыс.

(65) ну тестовый не суть.
так вопрос другой. а 7 сеансов с удалением элементов еще и с транзакцией.. не замедлят ли работу...

это не то же самое что допустим удаление с диска ? ... когда у тебя допустим 2 файла по гигабайту на диске.. если ты удалил 1 он удаляется 10 секунд.. а если ты запустил сразу два файла удаления то они уже даляются 20 секуд... и по факту получается одно и то же. что ты удалил по очереди два файла, что ты удалил их одновременно но двумя разными удалениями, то есть два раза мышкой тынклу удавлить)(

(59) Если Счетчик % 200 = 0 Тогда

(70) красивое

можно и на дробную часть сослаться)

(69) попробуйте, от вас не убудет

Да попробую то я попробую ;) только все эти тесты и манипуляции то же время ;)
сейчас по факту будет что пока я тут тестирую и консультируюсь) быстрее было бы запустить как есть уже бы шло удаление )

Многопоточность спасет инициатора

Кстати пока тестировал удаление.. был удивлен...

Запрос.Выполнить.Выгрузить и далее
для каждого стр из результат
тут удаление
цикл

Работает в разы быстрее чем
Запрос.Выполнить.Выбрать
Пока Результат.Следующий
удаление
цикл

я имею ввиду общее время от начала до конца обработки ;)

(75) а то что предложил Kassern выше это не многопоточность?

(74) возьмите не 100тыс, а 30тыс. Это должно занять у вас чуть меньше часа в одном потоке, и раза в 3 быстрее в три потока по 10тыс. В общем час тестов, зато можете сильно сэкономить время, в зависимости от возможности вашего железа

а обменданными.загрузка = истина не поможет? при условии, что есть регистры с измерениями, где флаг "Ведущее" установлен и типом удаляемого справочника. правда и этот мусор потом придется подчищать...

(79) обменданными.загрузка = истина
как то влияет на удаление дока наглухо с 1с ?)

элемента справочника

по теме (0) удалось тесты провести? есть прирост?

(80) эксперимента ради - создай тестовый справочник и тестовый рсв с измерением, для которого установи флаг "Ведущее" (тип - наш новый справочник). создай элемент, добавь запись в рсв с этим элементом, удали элемент справочника (без флагов и прочего). а потом посмотри - что осталось в таблице рсв. и вот если не путаю, то как раз обменданным.загрузка отключает очищение всех этих "вспомогательных" данных

(82)  50-он сообщение

(83) Так у меня нету вспомогательных данных...

у меня элемент справочника номенклатура. там только название и артикул и ставка ндс из справочника..
ни в какой рсв по ней ни чего не записано

(85) Извини, но ты занят какой-то х..ней.
Что создание, что удаление, напрямую в скуле для такого объема займёт секунды, ты же занят непойми чем.

(86) Это же надо скуль открывать и прямые запросы писать, а в лиц соглашении черным по желтому написано, что так делать ай яй яй)

(86) Да я не умею писать на SQL запросы, че ты хочешь то )) я вкурсе что в sql это будет быстрее..
Я там умею только лог почистить) ну грохнуть что нибудь без отборов и т.д.


Ну вот расскажи мне.. как мне в SQL найти дубли наименований + артикл.. то есть если и артикул и наимееование одинаковое

При этом после этого из этих двух одинаковых позиций нужно удалить только ту, по которой не было движений (поступлений там продаж, установок цен и тд)

(85) да просто проверь. делов то

я могу в sql грохнуть вообще всю номенклатуру под "0" )))) много ума не надо)

(88) селект не нужно прямым делать. в 1с селект и так прямо транмлируется

(89) да проверил. разница и правда лучше... если написать обменданными.запись=истина... но опять же не критичная... в паре тройку секунд

(91) (86)  Да не знаю я как в sql написать запрос.. если это так легко и быстро, то накидайте я в тестовой тестану

Мне надо для начало удалить номенклатуру дубли, где артикул и наименование одинаковые между друг другом.

потом нужно удалить номенклатуру где одинаковые артикулы (при этом пустые не учитывать) ибо есть позиции с пустыми артикулами

при этом нужно учесть во всех вариантах что номенклатуру по которой было движение удалять не стоит)

(93) Тебе все уже написали в (9) же.
Отличия только в DELETE. Остальная часть запроса может быть такой же как у 1С.

(94) Получаешь селектом табличку, где count>1 при group by наименование и артикул, потом delete ту, которая нот ин (селект номенклатура из нужного регистра) всё.

Монопольный режим так и не попробовал?

(96) а как потом проверить, что из 6лямов номенклатуры ничего лишнего не удалилось?) Где в вашем варианте проверку на ссылки к другим таблицам? "при этом нужно учесть во всех вариантах что номенклатуру по которой было движение удалять не стоит)"

(98) при любой схеме учета, номенклатура всегда торчит в одном регистре (обычно, товарынаскладах), максимум в 2-х разных, если какая то стороння, типа на комиссии. Проверять остальное смысла нет

(98)  вот и я про тоже. Где в sql проверить были ли движения по ней и стоит ли установка цен или нет. Выбрать однинаквлые по артикулу это пол беды

Можно и не в регистре проверить, а в табличной части дока, их будет всего пара - приход и возврат от покупателя, максимум, оприходывание, если есть

(99) правильно товары на складах. Только нужно проверить не остатки а были ли движения.  Так это мне сюквелом ещё надо проверить доки была ли эта номенклатура ). Так я совсем запутаюсь

(97) монопольный попробую. Уже убежал с работы. Но помню про него.

(102) в чем запутаешься ? в запросе к одной табличке регистра ?

А можно еще тупее, удалить по min(_idref)

Точнее, минимум оставить, а удалить максимум с ссылки

(104) Если говорить о номенклатуре, то там полно регистров. Это и цены номенклатуры, и Аналитики различные, штрихкоды, сегменты и т.д.

(100) Да еп..
Проверяй в 1С. Удаляй в скуле.

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

Самый идеальный вариант, это пометить на удаление именно те позиции, которые 100% будут удалены и ссылок не имеют. Тогда простой запрос с отбором на пометку удаления

(109) Это было сказано еще в (9)
Тут, видимо, проблема гораздо глубже)

Да даже временная таблица не нужна. Я прям строки через запятую передаю в подобных случаях)

(111) пробовали так для 1кк позиций и более?

(110) так блин. В том то и проблема. Что бы пометить на удаление такое же количество номенклатуры. Это столько же времени. Пометка на удаление.  
Записать.

Делается не быстреее.
Чем удалить ()

все не читал, но судя по названию темы, вы все таки смогли успешно перенести 4.5 млн позиций в базу из прошлой темы про ускорение загрузки?)

(112) Разбить на десять запросов?
Ну короче, это уже дело техники.

Я не знаю, как из csv во временную табличку в скуле загрузить. Как?

(115) с помощью OPENROWSET попробовать https://docs.microsoft.com/ru-ru/sql/t-sql/functions/openrowset-transact-sql?view=sql-server-ver15

(115) ТСКЛем наверно
а вобще если есть возможность сделать нужный отбор на скл, то это и использовать

(116) Спасибо. Надеюсь, не пригодится :)
Да, конечно, если файл большой, то лучше читать его инструментами, которые предназначены для этого.

(114) да загрузилось норм. Теперь все в нужных папках и категориях.)

А в скуле в таблицах есть поле какое то по которому можно понять что данная позиция создана позже чем другая. И следовательно ее нужно удалить

(120) по коду можно ориентироваться, в крайнем случае по гуиду

(120) есть _Version например или ссылка Ref, но они шестнадцатиричные, сравнивать на больше меньше думаю можно, муторно правда

(122) кому муторно?

хотя..

(121) код. Не число. А строка. Это что бы автоматом сравнивать коды на больше меньше. Надо их сделать числом. А там буковки в начале есть. Надо удалять. Это ещё плюс к мароке и времени

(125) с каких пор нельзя сравнивать строки?

Ладно завтра в тестовой базе попробую через скуль что нибудь сделать. Будем на связи ) всем спасибо

(125) ну ссылку можно взять, стремно показалось, что они увеличиваются всквозную по базе, а не отдельному справочнику, _Version вроде по справочнику

(126) н де, да сравнивать то можно, только результат какой будет?

(126) сравнивать строки с буквами на больше меньше ?)

(130) да! это же один С, она все может **мнение буха

(131) это да. Не напоминай. Это точно так же. Ну ты же программист выбери мне пылесос

(120) Нет. Все те же поля, что и в предприятии +/-

(132) не поверишь, у меня с пылесосом так и было! лет много назад, правда я одмином был, но один хрен логика железная)

(8) Я проверял - быстрее.

если ссылок нет грохай в скуле и все.

(130) ты реально не знаешь как выполняется сравнение строк или прикалываешься?)

(4) "С чего вдруг запись в транзакции должна быть быстрее?"
С того, что вместо Создаем Запись - Пишем на Диск - Создаем Запись - Пишем на Диск - Создаем Запись - Пишем на Диск - ...
Переходим к Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Пишем большой блок на Диск - ...

Тестирую удаление на 100к позиций из папки ном в иерархии.. не суть.
запросом, выбрал нужную ном из нужных папок.
получил 102к количества.
Далее со всеми возможными штуками  обменданными.загрузка истина и транзакцией по 2к штук (ради теста). поставил удаление.

поставил ушел курить... прихожу через минут 5-10. удалилась давольно быстро. Открываю справочник, эту папку во втором окне смотрю и да пусто... открываю первое окно с обработкой удаление.. а оно еще висит. подумал что за бред. папка пустая а обработка все висит.
Открываю журнал регистрации. и вижу строчки Данные.Удаление и следователньо позиция номенклатуры.. то есть грубо говоря еще удаляет.
То есть получается транзакция у меня по 2к строк. в номенклатуре в папке уже "0" то есть я их уже не вижу.
Но обработка работает и до сих пор в журнал записывается удаление.
Причем транзакция по "пакетам" работает я ее тестил то есть фиксирует по количеству указанному

Если он не удалил еще всю номенклатуру, почему тогда в папке ее уже нет? ни глазами, "ни запросом"
Если порция транзакции 2к, то почему до сих пор в журнал регистрации пишется удаление и обработка все еще работает.

(140) А фиг знает, что и откуда там ТВОЯ программа удаляет. Может пытается удалить то, что уже удалено, падает с ошибкой, а ты в обработке исключений заставляешь ее выполнить эту операцию еще раз.

Так ладно с удалением понятно удаляет более менее норм 100к позиций минут за 15.. приемлемо...

А как оптимизировать теперь проверку на движения...
Есть запрос, который отбирает дубли по артиклу. и выводит. список дублей
всего их 2кк, это и правильная позиция и дубль.
Дубли надо удалять только из определенного родителя. следовательно остается 1кк дублей истенных.
Ноооо по этим 1кк реальных дублей, могут быть движения (поступление товаров как минимум). следовательно такие удалять не стоит)) ибо объект не найден нам не нужен.
Следовательно 1кк дублей, нужно проверить как минимум по регистру ТоварыНаСкладах

Как продуктивнее это сделать? там же в запросе или при удалении каждую позицию проверять по регистру накопления?

поиск ссылок работает почти с одинаковой скоростью для 1 элемента и для 10к элементов.

(143) ну то есть я запросом отбираю дубли которые считаю надо грохать. остается 1кк
и далее при удалении ищу на каждый дубль ссылку? если нет то грохю

(138) скуль работает не так
Гугли про журнал транзакций и чекпойнт

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

(146) Как ты предлагаешь мне обработать 1кк номенклатуры на поиск ссылок руками ?)

может эти 1кк номенклатуры програть в РН товары на складах (за определенный период). типо если нет значит удаляепм если есть ну значит есть

(147) а что, на другие регистры пофиг?) Если это УТ11, то я бы ключи аналитики смотрел в первую очередь и иже с ними.

(147) самому имеется в виду не использовать ПоискСсылок() от 1с
а писать свои обработки которые будут как то частями проверять и лопатить не по всей базе а только там где ссылки могут быть.

(148) так у нас там ни чего нет если не было ни каких поступлений на склад. значит нет ни картинки, ни установки цен, ни каких то файлов, ни чего.

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

(151) я так и не понял как в скуле проверять на движение допустим товаров на складах
отобрать в скуле дубли по артиклу это одно. а проверить их потом по РН это уже другое)

(152) делал поиск неиспользуемых 1 запросом.
работает быстрее чем найти по ссылкам
https://drive.google.com/file/d/1CBzki0Hqn2GyxgyXvf7IxmEcf38XYGyA/view?usp=sharing

(153) благодарю


Кстати интересно а как "количество" порций в транзакции влияет на время??
на малых количествах 10-100-1000... ни как не влияет..
то есть если записей 1000
то хоть разбй их по 10 хоть по 100. хоть сразу в одну транзакцию.. время не меняется (ну может мили секунды).

А если речь идет о 1кк (протестировать на 1кк нет возможности).
если 1кк разбивать допустим по 10к порций или по 30к порций.. будет ли какая-то разница?)

(153) Забыл про общие реквизиты, системные поля, системные табличные части, регистры расчета и бухгалтерии. Отчасти поэтому оно и работает быстрее универсального поиска.

(145) А х.з., вот тут транзакции ускорили запись на 25% https://курсы-по-1с.рф/news/2017-03-27-four-methods-of-write-acceleration/#recording-in-transaction-not-used

Вопрос...
Если началась транзакци... потом закрылась 1с.. не дойдя до завершитьтранзакцию или отменитьтранзакцию
То она потом сама вернет все в зад или надо что то делать?

(157) вернет все в зад, так как данные не записались в таблицу.

это как документ, вы можете в нем править что угодно, но пока вы его не запишите (зафиксируете транзакцию) данные в базе не обновятся.

(159) А если сервер ребутнулся еще в этот момент, то все равно вернет или уже нет?

я сделал пакет по 50к..
запустил... пошла транзакция... до 50к она не дошла поэтому фиксации не было.
сначала закрылась 1с... че то там админ химичет с сервером...
я открыл заного. запустил обработку... Но выскачила ошибка.. транзакции не помню дословно но что то из серии не возможно начать транзакцию или блокировка не помню.. видимо потому что та еще шла.
А потом сервер вообще ребутнулся

(160) вот вы правите документ, указывает организацию и контрагента и в этот момент у вас вырубается комп. Вопрос, документ будет записан в базу? Вот тут так же

(152) ну как маленький, на вот, удаляй сколько влезет:

delete from _Reference12345 --подставишь свой справочник
where _IDRRef in (
select max(_Reference12345._IDRRef) from _Reference12345
where Fld12345<>''
group by _Description,Fld12345 --подставишь своё поле с артикулом
where Fld12345<>''
having COUNT (_IDRRef)>1)

в group by еще и ,_Folder воткнуть, мало ли, ты там налепил групп с одинаковым наименованием и артикулом

(113) может просто пометить скл все дубли на удаление. потом средствами 1с удалить что удалиться и скл снять пометки на удаление.
Мололи может товар только набрали. заказывают. пришел на склад и т.п.

И вопрос а точно нужно искать дубли артиклей и наименований или можно все товары пометить отменить пометку для созданных за последние несколько дней и средствами 1с грохнуть все что негде не используется. Точно нужно реле которое хотели заказать но так никогда и не заказывали и не продавали даже если у него нет дубля.

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

в общем я уже поставил на удаление 1кк номенклатуры. посмотрим вроде 200к уже удалилось. думаю за сегодня пройдет)

Нормельное идет... когда писал 169 соощение было 1.020 миллиона.
Сейчас уже 920 тысяч. ;)

(4) > С чего вдруг запись в транзакции должна быть быстрее?
Платформа на commit'е выполняет некоторые действия.
Если писать X объектов каждый в своей транзакции - эти действия будут выполнены X раз, а если в одной - один.

(171) а подробней? что за действия?

(0) в файловой базе в транзакции сильно быстрее операции выполняются. ибо только в ОЗУ
в серверной - транзакция не влияет на скорость

(173) у нас серверная.
Не влияет на скорость, но хотя бы не уменьшает ее ?)

(174) чутка уменьшает ибо блокировочки то держатся до конца трпнзакции

(175) (173)  Получается сколько людей столько и мнений... так как в двух темах есть люди которые "за" транзакции...
но на сколько я понял они аппилируют во сновном... темой... из серии записи на диск..
можно 10к файлов, записывать на диск 10к раз
А можно эти 10к файлов, типо объеденить в 1 большой и записать 1 раз.
И в случаи с виндой это быстрее...
Банально если разархивировать 10к маленьких файлов или 1 файл такого же объема как 10к маленьких... то 1 файл разахивируется быстрее )) я образно . хотя объем у них одинаковый

Ладно вернемся к нашим баранам...
Собственно тесты продолжаются ;) сейчас запрос готов.
я там учел все что мне надо. и конкретные папки, и заполненные артикулы ну и прочие штуки которые нужны...

Конечный результат запроса
//тут еще запрос, но он не важен отбираю дубли.
|ВЫБРАТЬ
                 |    Дубли.Артикул КАК Артикул,
                 |    Дубли.Ссылка КАК Ссылка
                 |ИЗ
                 |    Дубли КАК Дубли";

Следовательно получаю список дублей(ссылок номенклатуры) которые реально дубли.

Осталось эти позиции проверить по РН ТоварыНаСкладахОбороты, то есть если эта номенклатура фигурировала там то следовательно пропускаем ее.

Я вот думаю, может это дописать как то в конечный запрос. или засунуть результат запроса в массив и сделать следующий запрос по РН этому со списком из первого запроса
думаю перебирать в цикле каждую из позиций дубля, на наличия ее в РН будет явно дольше

(176) тесты все решат. Но никто их не делает

(176) мс скуль - это вообще как  ос внутри ос. Там и управление памятью свое и диском

Конечно с проверкой номенклатуры по РН товаров, в разы дольше работает.... видимо если проверку по РН сделать в запросе в том же где дубли бдует быстрее

(180) ну так и сделай в конце
где НЕ ссылка в (выбрать из регистра)

вроде сделал. сейчас посмотрю на сколько долго такой запрос будет по отношению к запросу без проверки по регистру.
а то может и смысла нет)

Короче

из 1.122к позиций

1120096

1120439

в регистра меньше 300 штук.

Запрос на проверку с регистром и без. отраатывает практически одинаковое количество времени разница вообще не значительная ;)

я так понимаю если в первом варианте количества позиций меньше ) значит проверку по регистру в запросе я сделал верно)))

Я так добавил

ГДЕ НЕ Дубли.Ссылка в (ВЫБРАТЬ
                 |    ТоварыНаСкладахОбороты.Номенклатура КАК Номенклатура
                 |ИЗ
                 |    РегистрНакопления.ТоварыНаСкладах.Обороты(&Период1, &Период2, Авто, ) КАК ТоварыНаСкладахОбороты)

Реально думаешь что кто то набил миллион левых записей и потом из них юзал только 300. Есть смысл так сайт перегружать.

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

(185) Ни кто не набивал позиции. Номенклатура сливалась из двух других баз + прайсы поставщиков.
Ранее и я так понимаю не очень "удачно"..
Из 5 миллионов номенклатуры, по артикулам+ наименованию получился 1 миллион дублей.

А эти 300 позиций которые "УЖЕ" используются... в полне реально. Так как в было всего штук 20 поступлений и штук 10 реализаций. Организация новая

(186) Смысл в том что это все импорт и сроки доставки не 1 день ессесно и не 2-а. и на складе в 90% случаев товара нет. 50% юр лица 50% физ лица..
для физ лиц и сделали сайт. выкладывать туда только 300 товаров со склада нет смысла, потому что товар специфичный и кому надо готов ждать и неделю и две и три. так как цена дешевле чем на сайтах у кого есть в наличии грубо говоря.
Следовательно хотят сделать норм номенклатуру и вывалить на сайт для возможности оформлять заказ.. поэтому и такая ситуация как то так

(188) Тогда я бы вам рекомендовал смотреть ссылки не только в Товародвижении, а еще и в Заказах, а то покупатель Заказ сделает, товар еще не приедет, а вы ссылку на товар уже грохнули. Потом тяжко будет вспоминать, что и кому должны привезти.

(189) так заказов с сайта еще нет. сайт оффлайн

сейчас только поступление реализация и заказы. введеные руками в базе от юр лиц.
в общем сложности документов 100 наверное вместе. при этом все заказы закрыты ;)

а так то понятна логика ваша

Ну а установку цен я и не проверял. там реализована загрузку и из экселя и как угодно там ни кто руками не заполняет. если будут объекты не найдены. загрузят еще раз. на эти 300 позиций)

на сайте все равно 0 товара в данный момент и сайт офф

А таки удаление через свой код быстрее чем стандартное Удаление из программы?

(195) что за "Удаление из программы"

(196) Стандартная функция из Обслуживания - Удаление помеченных объектов.

(197) так она же все ссылки ищет.
Оно никак не может быстрее 1 запроса работать. Ибо все найденные сслыки со скуля возвращаются

(0) если бы семерка былабы там действительно быстрее в  транзакции

200!

(197)
Запрос на дубли (с отборами нружных папок в иерархии) со сравнением артикла и наименование
далее с проверкой на вхождение их в РН товары на складах
Все это в одном запросе
Далее результат.выгрузить
И далее в транзакции пакетами по 50к штук

Удалил 1.120.000 позиций, за пол дня.
Не так уж и плохо. "без Монопольного режима, но в базе был 1 человек который делал отгрузочные новые доки для контрагентов"

А стандартная функция удаление помеченны объектов это в любом случаи дольше.
Так как сначала нужно будет провести все те же манипуляции выше, только вместо удалить().. будет пометканаудаление.истина , записать().
то есть нужно будет 1кк номенклатуры прогнать, пометить и записать
А потом еще запустить стандартное удаление. которое будет проверять на ссылки (даже если их по факту нет) и далее еще удалять )