Регистр сведений проверка на уникальность #754391

Есть регистр сведений с 3-мя измерениями, Код(строка), номенклатура, строка. Сейчас идет проверка уникальности только по номенклатуре и по коду, надо сделать уникальной и строку. В свойствах что-то не нашла ничего ... Или перед записью нового элемента надо перебирать весь набор записей и проверять на соответствие?

, читайте 33 комментарий

Спасибо, сделала уже так:

=)

И что это значит "=)"?

вот бы придумали такой механизм, который сам бы контролировал уникальность записей в таблице по какому-то набору полей...

- это намек, что такой способ есть или просто мысли в слух? ) Потому что я искала, ничего похожего не нашла ...

Для начала запрос в цикле без "ГДЕ". Затем ты говоришь, что у тебя 3 измерения регистра. Платформа не даст сама тебе сделать запись с одинаоквыми ключевыми полями.

именно намек.

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

Может ссылочкой кто поделится ...

Ну так сделай его единственным измерением и все

тогда у тебя одно измерение

не вариант, так как уникальными должны быть 2 кода. Это делается для обмена. Код в первой базе и код во второй соответственно.

выходит, у тебя два измерения. что за строка?

Два измерения дают тебе отношение многие ко многим. Одно измерение и один ресурс дадут тебе отношение один к одному.

щито? (изм1 - рес1, изм1 - рес2) - это один к одному?

этот вариант невозможен, он правильно говорит

И итог то какой в ваших дебатах, господа? ))

Ну ищи запросом, только переделай. Можно еще разделить на 2 регистра

Не, лучше запрос, а чем этот не вариант? У меня сначала так было: Запрос = Новый Запрос("ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 1     СоответствиеНоменклатурыИнсталлКНР.КодИНСТАЛЛ ИЗ     РегистрСведений.СоответствиеНоменклатурыИнсталлКНР КАК СоответствиеНоменклатурыИнсталлКНР ГДЕ И второй, только к другому. Это лучше?

В ГДЕ просто добавь ИЛИ и второго запроса не нужно. И все равно не комильфо, ибо запрос в цикле. Тем более запрос, который шерстит все записи по регистру.

не проще срез последнеих в объектной модели по нужному измирению смотреть?

вангую, что РС не периодический

Идея в том, что мы не дергаем базу в цикле.

Можно дальше оптимизировать, например передавать в запрос список реквизитов и смотреть на результат.

тогда просто получить

Вариант синтаксиса: Для непериодического регистра Синтаксис: Получить(<Отбор>) Параметры: Тип: Структура. Структура, содержащая отбор по измерениям регистра. В переданной структуре должны содержаться те измерения, по которым должны быть отфильтрованы записи. В элементе структуры задается имя и значение отбора. Должны указываться значения для всех измерений. Параметр обязателен для регистров, имеющих измерения. Структура дополнительно может иметь элементы, соответствующие разделителям регистра с уровнем разделения НезависимоИСовместно, в состав которых входит регистр. Если такой элемент структуры задан для используемого в сеансе разделителя, значение для этого элемента должно совпадать со значением разделителя, иначе будет вызвано исключение. Неиспользуемым в сеансе разделителям регистра в структуре должен соответствовать элемент с указанным значением отбора, так же, как для всех измерений, иначе будет вызвано исключение. Если параметр не указан, то отбор не используется. Возвращаемое значение: Тип: Структура. Структура, содержащая значения ресурсов. Описание: Получает ресурсы регистра сведений по указанным ключевым полям.

В цикле это будет аналогично запросу.

Только тут две строчки а с запросом 10ок

не в строчках дело, а в оптимизации

норм вармант

смешно.

И что же тебя рассмешило?

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

Ну мы-то можем рассуждать, а вот тебе до понятия оптимзации по ходу далеко еще

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

Как думаешь, в какой запрос трансформируется метод .Получить при обращении к БД?

как думаешь что проще получить результат или индексировать создавать тзх и исктаь в ней?

Если твой результат получается путем запроса как в в цикле, то нахрен он нужен. В нужно только отбор в запросе наложить и все

Забавно. Два уникальных ключа. Получается, нужно два справочника создавать. Или слепить два кода в один, что будет лучше.

А нет, слепить не получится. Только два справочника.

А и два справочника не нужно. Один индексированный реквизит в дополнение к коду решает проблему.

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

Все бред. Так и непонятно, для каких таких обменов нужна такая головомойка? :)

Вообще не понял из за чего сыр бор. Чем набор записей РС не угодил?

Перед записью делаешь отбор по текущим данным - какой накуй цикл???

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