В ТабличнойЧасти документа могут быть одинаковые "Наименования". Но, при этом должны различаться "Комментарием". А вот с одинаковыми Наименованиями/Комментарием не должно быть. Как правильно осуществить контроль/проверку?
В процедуру ПередЗаписьюНаСервере выгрузить ТЧ в ТЗ колонками "Номенклатура" и "Комментарий". В третью колонку проставить 1, затем сгруппировать по первым двум суммируя по третьей и если в оставшихся строках будет >1 сообщить пользователю "Наименование/Комментарий" и отказать в записи.
Или есть способ лучше?
---
Можете использовать поиск в цикле. Если проиндексировать ТЗ по колонкам поиска, то работать будет быстро.
---
Или есть способ лучше?Ну любой способ - это способ. Лучший способ - это минимальное время + минимальный расход памяти.

Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.

Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))

Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).

Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.

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

В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.

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

Но как бы всегда можно проверить.

Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
---
Поиск в цикле
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
---
Я бы при добавлении строки сразу проверял на наличие дублей. Например, через НайтиСтроки()
---
Не годится. При добавлении по Номенклатуре проверяется. Выдается сообщение. И дубликаты допускаются. Лишь бы Комментарии отличались. Условно: Добавил номенклатуру "Труба". В комментариях ничего не прописал. Добавил опять "Труба", сообщил, что уже такая есть. При проведении - не дает. Но, стоит только прописать Комментарии, у первого на "Куст 1", у второго на "Куст 2" - все корректно проводится.
---
Или есть способ лучше?Ну любой способ - это способ. Лучший способ - это минимальное время + минимальный расход памяти.

Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.

Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))

Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).

Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.

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

В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.

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

Но как бы всегда можно проверить.

Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
---
Запрос было бы отлично. Но... проверить надо до сохранения в базу
---
до сохранения в базуНу передайте туда таблицу значений - не вижу проблем. Совсем тупо - передать таблицу, выбрать различные, получить количество строк, сравнить с количеством строк в таблице. Если не равно - ай-ай-ай.
---
Можете использовать поиск в цикле. Если проиндексировать ТЗ по колонкам поиска, то работать будет быстро.
---
.
---
Поиск в цикле
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
---
Если объемы не очень большие, то я бы посоветовал скопировать в таблицу значений, далее в цикле получать копию таблицы с отбором по ключевым полям. Если отобралось > 1 строки, значит есть дубль. Это будет очень простой и эффективный код.
---
Ну и удалять строки при наличии дублей, чтобы не сообщать о дубле больше одного раза
---
Ну и удалять строки при наличии дублей А по каким критериям? Какую строку будешь оставлять, а какую удалять?
Ну и вишенка - как будешь сообщать информацию о дублирующихся строках, если ты их удаляешь? Ну, например, интересует информация про номера строк-дублей.
---
далее в цикле получать копию таблицы с отбором по ключевым полям. Где возьмешь наборы значений для этих ключевых полей, чтобы прогнать их в цикле?
И почему именно копию? Что такое копия - 1) копирование структуры 2) отбор строк 3) создание новых строк 4) заполнение новых строк значениями отобранных
Все еще уверен, что именно копия спасет отца русской демократии?
---
Как вариант. Пойти на сервер. Выгрузить 2 колонки ТЧ в ТЗ. В ТЗ, добавить числовую колонку. Свернуть ТЗ. Пробежаться по ТЗ, в строках где в числовой колонке больше 1, там и есть задвоение.

Так же Кусты напоминают измерения, может создать такой справочник, и в документе вместо комментария выбирать Куст...
---
Так это автор в своем посте уже и сделал...
---
А ну да, пока читал комменты, забыл начало :)