Здравствуйте.

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

Гляньте «Администрирование», подраздел «Настройки программы» и в нём «Настройки работы с файлами».
Что с флажком "Хранить файлы в томах на диске". Стоит?
Или переключатель "В томах на диске"

(0) Справочник НоменклатураПрисоединенныеФайлы

В ERP 2.5.17 переходят с РС "ДвоичныеДанныеФайлов" - теперь он "УдалитьДвоичныеДанныеФайлов" - на РС "ХранилищеФайлов". При этом пока старые данные - в "УдалитьДвоичныеДанныеФайлов", а новые уже в "ХранилищеФайлов"

Думаю, в УТ - аналогично.

(3) В УТ 11.5.12.251 РС "ХранилищеФайлов" нет, может в более поздних релизах появился. (0) ТС, озвучь какой у тебя релиз

(0) У справочника "НоменклатураПрисоединенныеФайлы" есть реквизит ТипХраненияФайла, который ссылается на соответствующее перечисление, а у него значения: ВИнформационнойБазе, ВТомахНаДиске. Там же есть ПутьКФайлу (Дополнительный путь к файлу на диске (в случае если ТипХраненияФайла - на диске))

(1) "в информационной базе"

(2) Да, но ранее сам двоичный файл хранился в регистре сведений "ДвоичныеДанныеФайлов", а теперь  в конфигурации регистр переименован в  "УдалитьДвоичныеДанныеФайлов"

(3) Вот именно переименование в "УдалитьДвоичныеДанныеФайлов" меня и смутило в УТ

(4) Управление торговлей, редакция 11 (11.5.19.74)

(5)  "в информационной базе"

Я поясню, зачем мне это.
Ранее, можно было в отчете на СКД делать левое соединение к номенклатуре, прикрепив регистр "ДвоичныеДанныеФайлов" по полю Номенклатура.ФайлКартинки и тем самым вывести в отчете с регистра сведений изображение товара.
А теперь как нужно будет выводить изображение товара в отчете на СКД, если регистр "ДвоичныеДанныеФайлов" переименован и в 1С планируют его удалить?

(2) И это тоже. К вопросу о дичи.
В УТ11 для объектов надо создавать отдельный справочник "....ПрисоединенныеФайлы"

Какой мутант это придумал? Зачем?

(7) РС ХранилищеФайлов в твоем релизе есть? Или что-то похожее. Посмотри. Тебе же в (3) написали.

(8) вообще-то и в БСП для прикрепления файлов есть отдельные справочники для каждого объекта

(3) и (9) Да, спасибо, действительно, есть регистр "ХранилищеФайлов". База была закрыта, ждал пока загрузится.

(10) Вот я и спрашиваю: какая сволочь это придумала? Зачем?

(11) вот и собирай свой отчет по регистру из РС  "УдалитьДвоичныеДанныеФайлов" и РС "ХранилищеФайлов", а когда  
РС  "УдалитьДвоичныеДанныеФайлов" пропадет в новых релизах, будешь собирать только из РС "ХранилищеФайлов"

(12) по моему нормальное решение разделить хранимые файлы по объектам, а не сваливать всё в одну кучу. Опять же подключение новых (своих самописных) объектов к хранилищу файлов более понятное.

(14) Мне тоже нравится это решение, кроме суффикса "ПрисоединенныеФайлы", слишком длинный. Достаточно было бы "Файлы". А ещё лучше завести новый тип объектов в дереве конфигурации, на уровне "Справочники", "Документы". И так и назвать: "Файлы".

(14) "подключение новых (своих самописных) объектов к хранилищу файлов более понятное"

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

(16) в монстра у тебя бы превратилась таблица для хранения файлов, если бы она была одна. Из всей базы туда файлов напихаешь и база колом встанет.
Плюс, если не нравится хранить файлы внутри базы, есть возможность вынести их за пределы базы.

(12) Затем, что у присоединенного файла для определенного вида объектов могут быть свои дополнительные реквизиты, и своя форма (что используется в паре процентов случаев)... Можно было решить с реквизитами и другим способом, а вот с формой другие решения сложнее.
(14) насчет "понятности" и "простоты" подключения можно сильно поспорить...
(17) одна таблица, или несколько - по большому счету пофиг. Данных-то одинаковое количество. И оперативной работы с ними нет.

(18) Нет, не пофиг. Сваливание терабайт в одну таблицу гораздо хуже, чем размазывание их по десяткам таблиц

кроме того в случае отдельных объектов можно реализовать раздельное хранение и что-то например хранить в базе, что-то в томах, а что-то вообще выкинуть в облако или S3. с 1 регистром такое сделать проблематично

(19) там не терабайты будут - в справочниках "прикрепленные файлы" сами изображения не хранятся

(20) Если делать "одним справочником", то все равно для организации допреквизитов нужен справочник-описание, и РС для хранения реквизитов. В справочнике-описании вполне можно указывать место хранения...
На мой взгляд,  2 справочника + 2 регистра (а доп формы справочника файлов - в самом объекте) было бы проще и логичнее. Но возможно, что я что-то упустил...

(21) Вот и я про то же. Сами файлы все равно лежат в хранилище. Одной большой кучей.

(23) если они сразу по-нормальному сделают - что потом делать будут? а тут бесконечный процесс. Менять один справочник на много, переименовывать регистры сведений, переопределять определяемые типы... "у самурая нет цели, только путь"©. Что вызывает следствие "нас невозможно сбить с пути - нам похпофигу, куда идти"©

(3) В связи с этим перематерился в конце сентября, потому что при обновлении КА с 2.5.16 на 2.5.17 у меня отвалился функционал в АРМ с прикрепленными вложениями. И переделка часов на 30-40, которую надо как-то объяснять клиенту.

(25) Вот мне тоже непонятен мотив этих изменений. Регистр сведений "ДвоичныеДанныеФайлов" использовался многими для работы с изображениями, зачем его нужно было заменять на другой регистр, чтобы мы могли немного заработать на переделках доработок?

(25) Клиент мог бы и подождать пару лет. к тому времени в типовых бы вернули старый регистр. Такое уже бывало...

(26) Думаю - развитие в эту сторону https://wonderland.v8.1c.ru/blog/khranilishche-dvoichnykh-dannykh/

(28) спасибо, прочитал. в том числе и про "Развитие хранилища двоичных данных". Очередной велосипед с квадратными колесами... казалось бы, используй в качестве хранилища блобов отдельные базы на серверах БД, и получишь стандартную работу, стандартное управление БД, стандартное бэкапирование и прочие стандартные вещи... нет же, они решили прикостылить к кластеру собственный велосипед...