выбрать из справочника элементы по одинаковому наименованию #276061

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

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

запросом..

ПорядокНаименований, предыдущий сравнивать с последующим. Или то же в ТЗ - через запрос, но тоже перебор

В транзакции с отменой оной поиск по наименованию с переименованием...

а проще есть варианты? по типу цикла "выбратьэлементыпореквизиту?

Удаление в мнимой транзакции + НайтиПоНаименованию ...

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

рассматривается именно ситуация, когда наименования одинаковые.

//что может проше и быстрее 3 и 5 Думаешь запрос индекс использует?

Хм если база sql то может быть быстрее?

+ 1

Конечна нет ...

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

Тразакция работает быстрее??? Хм - проверю.

проверил, работает. но давольно-таки долго.

а можно про транзакцию по-подробней?

НачатьТранзакцию;

100% работает. Не раз использовал. Пока пользователей не задолбало

понял.

запросы -отстой. Не используй их никогда. Делай ПорядокНаименований и ВыбратьЭлементы с Тарзакцией (можно сохранить резултат в СписокЗначений в глоб модуле и обновлять и поворять ВыбратьЭлементы только когда Время файла справочника изменилось);

Запросы рулят. "выбратьЭлементы" - это для лохов

запросы = тромоза

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

ты не прав

1c++ канает? база скуль?

Слепцы! Говорю вам: запросы - тормозят. Они для ленивых

думаю, что самый оптимальный способ в . в данном случае поиск будет быстр. единственное, чтоб "пользователей не задолбало"))) сейчас забацаю. всем спасибо (кроме ниф-ниф, конечно).

ты не прав

Бредятина Где ты видишь прямой обход в НайтиПоНаименованию?

в ВыбратьЭлементы

+29 Не скажу как ведет себя скуль и не буду утверждать за Наименование, но запрос по сортированному реквизиту на ДБФ индекс не использует. Но под тем, что запрос=тормоз, я бы не расписался

А-а-а-, это все к 20 было? Ну да.... уже высказался :)

Может на Скуле запросы не тормозят, но с ДБФ версией я не раз убедился в . Всегда можно обойтись кодом вместо запроса, и код будет работать намного быстрее.

типа запрос это не код :)

?????????????? Тебе уже все сказал.

лучше так:

"но запрос по сортированному реквизиту на ДБФ индекс не использует." Сказал. Скажи ты - как запрос быстрее кода?

согласен. но что такое СпрНужный.ВыбратьСтроки; ?? Можно запросом просто выбрать все элементы справочник, выгрузить и в ТЗ обработать. По идее должно быть быстро.

Вроде не маленький, а такую чушь несешь...

Ты вроде уверен, но аргументировать не можешь. Может у вас у весх супер-компы с рэйд-масивом и 2яйцевимы процессорами, но на моем целероне запросы тормозят.

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

ВОзьми большой запрос - о как вариант отчет по продажам перепеши без запроса

При работе с регистрами - без запросов ни куда. Задача решается быстрее всего не запросом и не полным перебором

Ой...А оно точно работает?

О то ж :) Проверь

+ Просто свернуть в 100 раз быстрее отработает, чем сам будешь сравнивать предыдущий со следующим...

:) Это было - но коммент :)

И так видно что с багом.

Предложи что-либо эффективнее

3 и 5 пост....

Ну синтаксические имеют место. Я ж прямо здесь писал... Так точнее:

ага юзеров лочить...

Один фиг с ошибкой вылетает :)

СпрНужный.Количество - что такое вобще, может "=1" и все?

эт че СпрНужный.Количество

см 34,25.,20й пост: "Не используй их никогда" - это что, не бред по вашему? + 10, согласен на все 100.

Разумеется :)

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

Теперь все, в следующий раз буду в пофигураторе писать. Но вообще я тяп-ляп саму схему набросал, вот и накосячил по мелочи, но мелочи эти ловятся за 3 минуты... :)

со скулем быстрее, не спорю. "лишние телодвижения" - должно бы выглядеть как как считывание с винта с адреса 1 записи по послендюю и запись считанного в ОЗУ.

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

речь не о регистрах

Тьфу, блин сплю, так конечно:

А ты правда считаешь что многократные НайтиПоНаименованию + сравнения/изменения работают быстрее чем ВыбратьЭлементы Пока ПолучитьЭлемент?

ЛОЛ!!!

НайтиПоНаименованию + сравнения/изменения медленнее, т.к. позиция индекса постоянно сбрасывается

вот так и получается зацикливание ).

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

ссылку на элемент сохранить бы

началась уже откровенная тупость

Ну зацикливание там никак не получится, разве что в мозгах :) В общем накидал-то саму идею, а кинулись синтаксические ошибки исправлять и ушли от темы... Надо было на словах, перебором в ТЗ, ТЗ свернуть. Но вот объяснить с суммируемоей колонкой решил что проще кодом будет, да спросоня вместо =1 какую-то хрень написал. А уж ВыбратьСтроки, это вообще ни о чем, понятно что очепятка...

Не получится, не свернется тогда. Потом по наименованию найдешь

Один фиг нерабочий код :)

Ага. Ищите баги дальше...

Добавь ТЗ.НоваяСтрока и успокойтесь. Этот код и не должен был быть рабочим, хотя бы уже потому что отсутствует Справочник.НужныйСправочник. Цель была не в том чтобы скопипастил, запустил, заработало, а чтобы саму идею понял. Стебайся дальше, я пошел отсюда. ЗЫ: Вообще-то единственный эффективный вариант предложил, но нерабочий, что ты!.. Самому за три минуты баги исправить не судьба, сварганьте мне...

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

"нужно из нужного"))) извиняюсь за тавтологию.

Имха, для этого вариант с транзакциями подходит больше чем с ТЗ.

имха для поиска ВСЕХ дубликатов ТЗ больше годится

имха дя поиска всех дубликатов больше сгодитсо select

мда

10 тыщ дубликатов из 40 - возникает вопрос а нужно ли ваще наименование? Согласно теории информации получается, что практически нет :)

я к примеру сказал. в действительности где-то 500 из 35 тыщ.

Не больше. Можно сделать 2 ТЗ одну с остатками по всей номенклатуре, отсортированную по наименованию, потом как в находим повторяющиеся наименования, идем по таблице дубликатов, если КоличествоЭлементов>1 Тогда ищем в таблице остатков Наименование и пускаем цикл Для Сч = 1 по КоличествоЭлементов, в цикле ТЗОстатков.ПолучитьСтрокуПоНомеру(НайденныйНомер+Сч-1); и выводим остаток. Итого имеем один запрос, чтобы получить все остатки (или как ты их там будешь получать), один перебор элементов справочника (в случае запроса можно заменить на выгрузить), один проход по таблице совпадений, с частичным проходом таблицы остатков. Т.е. многократного прохождения справочника или таблицы не будет и отработает максимально эффективно.

=>

признаться, сам так делал...

хотя, признаться, отчет выполняется долго (через запросы еще дольше), поскольку дальше используются регистры, условия, проверки и т.д. вопрос: можно ли оптимизировать этот код (выше)? или есть другие варианты решения задачи?

а почему бы не воспользоваться 1с++...прямым запросом?

не умею.

у тя база скуль?

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

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

% заменяет любой символ...

100

а эта выводит все дублирующиеся элементы, то есть те у которых совпадают наименования