8.х Интересный вопрос о "Регистр сведений" и "Хранилище значений"

Добрый день!
Я создал регистр сведений для хранения произвольных данных.
Измерения "Имя1" (строка 50) и "Имя2" (строка 100) и ресурс "Данные" (ХранилищеЗначения).
Пока не поздно, решил спросить совета.
1. Если занчение Имя1 и Имя2 всегда будет меньше 50 и 100 символов, смогули я установить отбор по данному полю, например, по значению "ШишкиНаЕлке", или мне надо преобразовывать эту строку к "ШишкиНаЕлке " (т. е. + нужное число пробелов или каких там знаков)?
2. Хранилище использую, потому что тип данных может быть любой из тех, что могут быть на форме (и число и строка и ТЗ и т. д.). Как лучше хранить данные, так и писать для каждого реквизита (нужного) формы и сохранять в регистр или сначала сформировать ХМЛ файл, сохранить его во временный каталог и потом запихнуть в хранилище?

Это нужно для сохранения настроек формы.

Спасибо.

Задача какая-то мутная, решение тоже.
Хранить строковые значения в измерениях РС - зло.
Хранить значения разных типов в одном ресурсе типа ХранилищеЗначения - ИМХО, так же зло.

Необходимо четко определить роль РС и реализовать механизм согласно требований к функциональности всего механизма в целом.

Эм, ну да, видимо я решаю задачу в лоб
На форме есть ряд элементов (неуправляемая форма) разных типов значений ( в том числе и ТЗ с количеством строк до 50 и колонками в количестве 6-8) - это настрйоки отображения отчета (самописный).
Суть в том, чтобы один пользователь мог передать другому свои настройки.
Соответственно у настрйоки есть имя1 - имя отчета к которому они относятся, Имя2 - имя самих настроек (т. к. таких наборов может быть несколько).
Текущая реализация: сохранить в ХМЛ, сохранить в общем доступе или послать по почте, загрузить ХМЛ.
Возникло желание реализовать это в пределах информационной базы (благо она одна и та же).
Лучше ничего не придумал, как использовать регистр сведений.
Пока задал вопрос, уже реализовал это так: добавил имя3 - имя реквизита формы и сохраняю его значение в регистр в ХранилищеЗначений.
Работает отлично, и отбор устаналвивается независимо от длины строки, но вопрос актуален: может все же делать одну запись и грузить ХМЛ?

Конфигурация типовая?

Да, абсолютно.
Ещё раз оговорюсь - часто решаю задачу в лоб, чобы быстрее было Так что может мои решения не всегда красивые. Требовалось обмениваться настрйоками - ХМЛ. Надоело пересылать - регистр.

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

Это да, это видел, но так и не смог сохранить там ТЗ. Может просто не понял как это реализавать. СписокЗначений без проблем, ТЗ так и не разобрался, птому тогда и появился вариант с ХМЛ, ну а Теперь регистр.
В любом случае спасибо.

Сохраняется в любом случае - структура, а уж чего внутри структуры - дело 10-ое, хоть черта лысого хранить можно

Ой, ещё вопрос:
врЗапрос.Выполнить().Пустой() вызывает "У пользователя недостаточно прав на исполнение операции над базой данных" и вываливается с ошибкой, хотя в запросе стоит "Разрешенные".
Проме как через Попытка-Исключение эту ошибку никак не обойти?

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

Это я понял, а обойти эту ошибку сразу в запросе "Разрешенные" не помогает? Надо через "Попытку" выполнять запрос, чтобы отчет критически не вываливался с ошибкой? Просто не я админ по правам, так что надо как-то "защититься" от таких ошибок

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

Ну что ж, попытка не пытка Еще раз благодарю!

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