Каким образом нужно правильно это делать?

В обработке проверки заполнения

Как вариант

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

Перед записью контролировать неправильно

(4)почему?

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

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

(6)тогда при записи )

(8) Тоже неправильно)

(9)тебе не угодишь  (
в типовой поиск дублей делается передЗаписью

(7)создай тогда какую нить табличку и блокируй её, или блокируй всю табл справочника

(11) Если вся эта шняга затевается для того чтобы юзеры не били контров с одинаковым ИНН и вероятность наступления одномоментного ввода элементов с одинаковым реквизитами 10 в минус ХЗ какой степени, то зачем все эти геморрои?

(11) Блокировать всю таблицу не правильно, т. к. при этом снижается производительность системы. Кроме того как это сделать?
(12) Нет, ИНН здесь ни при чем. Речь о многопотоковой параллельной работе со справочниками.

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

А чо, ПриИзменении не подойдет?

Перед записью запросом ГДЕ МойСправочник.ИмяРеквизита = &Реквизит

(13)>>Кроме того как это сделать?

в транзакции ДЛЯ ИЗМЕНЕНИЯ, или неробит?

(7) Воспроизведи.

(18) Я должен воспроизвести? Можешь мне поверить, или проверить)
(14) Почему с 2-мя измерениями? по моему измерение должно быть одно - реквизит, проверяемый на уникальность. ну и ресурс можно сделать - ссылка на элемент справочника....

(17) ДЛЯ ИЗМЕНЕНИЯ в режиме управляемых блокировок вроде не работает

1) первая проверка:
ПередЗаписью - пробегаемся по всему справочнику
Здесь же записываем значение реквизита (которое вводится сейчас) во временный РС "ЗначенияКоторыеВводятсяСейчас"

2) вторая проверка
ПриЗаписи - смотрим РС "ЗначенияКоторыеВводятсяСейчас", нет ли там таких значений, вводимых в данный момент другими (с полной блокировкой этот регистр)

3) Периодически (тут надо подумать) чистим наш вспомогательный РС (блокируя в этот момент таблицу справочника).

Ессно, в файловой версии это работать не будет. Да и в постгри, наверное, тоже.

(19) да, с одним измерением круче, можно прямо в ПриИзменении реквизита на форме проверять.

(21) Хитрый алгоритм, насколько он оптимален с точки зрения производительности? Особенно такие моменты как "ПередЗаписью - пробегаемся по всему справочнику "...

(22) Меня больше интересует программная запись)

Насчет регистра сведений - это вы загнули. А с учетом многопользовательского режима работы - совсем уж лишнее. Пятое колесо в телеге :)

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

(24) почему? Зато уникальность сама по себе будет контролироваться. На уровне платформы. И как раз это для многопользовательской версии, для однопользовательской это не нужно.

(25) нужно еще учесть тип значения или у вас строка?

(27) Строка, длиной больше 254 символов...

(28) все-таки вводить регистр сведений для уникальности будет избыточно. Даже если открыто одновременно две формы у разных пользователей... Можно в код ПослеЗаписи поставить запрос по этому реквизиту, если выдаст более одного значения в результат, то вот и получишь поиск неуникального. Если же искать среди не записанных, в том числе и без самого себя, то гарантированного результата не достигнуть, имхо

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

(23) В любом случае понадобится таблица, хранящая все значения. Хоть тот же справочник, хоть отдельный РС (в том случае, если реквизитов в справочнике ну очень много, чтобы таблица была меньше).
Речь вообще про какие объемы? Сколько элементов в секунду будет вводиться?

(29) ПослеЗаписи, когда транзакция уже зафиксирована и данные внесены в БД, в случае не уникальности реквизита, придется удалять записанные данные, кроме того в этом случае возможна ситуация когда оба одновременно записываемых элемента (в случае 2-х конкурентных потоков) с одинаковыми реквизитами будут удалены

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

+ кстати, для объекта справочник события ПослеЗаписи нет)

(33) насчет типового решения не могу ничего сказать, т к не видел его

(26) Хм... на "уровне платформы"... Это об той самойплатформе речь, где функционал распределенной информационной базы встроен. Риб-база - и все ваши "навороты" для обеспечения уникальности становятся бессмысленными.

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

(28) Можно подробнее, что хранится в этом реквизите?

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

1) Сериализовать все изменения сущности (будь то справочник, регистр и т.д.). То есть блокировать некий общий ресурс перед записью, проверить уникальность, записать, снять блокировку. Платформа позволяет это сделать несколькими способами.

2) Ввести ограничение уникальности на уровне СУБД (unique constraint или unique index). Тут есть такие варианты:
а) хранить данные, требующие уникальности, в реквизите, для которого платформа сама создает в БД такое ограничение (например код справочника, единственное измерение РС (19));
б) создать дополнительное ограничение самостоятельно через SQL (и самому же его поддерживать, платформа о нем не знает и может его снести)

(38) Вариант 2-б мне нравится можно попробовать)

(38) Хранится строка, содержащая url-адрес.

(40) Похоже на самостоятельную сущность. Подумайте о 2а.

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

(42) Вычислите хэш от URL и сделайте его кодом справочника (или частью кода).

(43) Он точно будет уникальным?

вот стоило бы в самом начале указать, какого характера инфу сохранять и получить совет из (43)

(45) Хэш не гарантирует уникальность

(46) md5 ?

(19) Ну вот я какбе и не верю.

(47) http://habrahabr.ru/qa/7640/

целая дискуссия по поводу использования md5 хэшей в качестве примари кей. Тут не все так однозначно

(48) Проверь)

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

(44) Не точно. Добавьте проверку на коллизии. Можно еще один разряд добавить на случай коллизии, но я бы не стал.

(50) Не нашел там серьезных аргументов против. Кроме того, Код это не primary key.

(42)делай подчинённый справочник, код у которого твой уникальный реквизит, ессно должна быть уникальность кодов

(54) Длина кода ограничена

(51) Вот я и говорю: воспроизведи для начала.