Привет!
Есть база ут, где есть фотографии номенклатуры, и есть розница, где элементы номенклатуры имеют аналогичный код и где хотят видеть фотки. Думаю:
1.создать реквизит в УТ, в справочнике НоменклатураПрисоединенныеФайлы, "ВыгруженоВРозницу"
2. Подключиться из розницы через COM Коннектор

Коннектор = Новый COMОбъект("V83.COMConnector");

3. Где реквизит "ВыгруженоВРозницу" загружаю в Розницу.

Может есть вариант проще?

а релизы платформы одинаковые? А то могут быть проблемы с подключением

http

(0)

А типовой обмен УТ->Розница, картинки не умеет переносить ?
Посмотрел - умеет.

Ну и нахрена козе баян?

план обмена для хранения регистрации изменения

Обычный типовой двухсторонний обмен, но у одного из узлов, непосредственно перед обменом, -  ПланыОбмена.УдалитьРегистрациюИзменений(...)

PS: но что будет, если в этом узле (без регистрации изменений) объекты разрешено изменять/переименовывать/удалять? Вот в чём вопрос.

(0) COM - забыть как страшный сон. Можно вообще через общую папку, где подпапка - код товара, а внутри фотки.

"ИД" фото сделать одинаковым в двух базах.
фото хранить на внешнем каталоге.
в двух базах "прописать" путь к внешнему каталогу.
нахрена какие-то обмены?

(7) Так себе идея. Из разряда вредных советов.

(0) обмен по http если хочется прямо, чтобы в базе хранились, можно на каком-нибудь ресурсе хранить и просто ссылку передавать. Вариантов море, вопрос в ресурсах и хотелках

(8) обоснуй

Все файлы хранятся в иерархической базе данных под названием "файловая система".
Да, всегда можно засунуть файл внутрь базы данных в поле типа BLOB. Но с точки зрения файловой системы просто усложнится доступ. Теперь нам понадобится отдельный "драйвер" для файлов этого типа, СУБД, причём ещё дополнительный API.
Так что предложение (7) элегантное и грандиозное!
Главное, чтобы не разошлись идентификаторы объектов в БД и пути в файловой системе.

(11) проблема возникает когда у нас базы физически на разных ресурсах. Тогда я бы сделал публикацию картинок на веб-сервере и передача URLов

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

"нахрена какие-то обмены?"

При этом обмены всё равно нужны - как-то придётся обмениваться путём к картинке и ИД фото.

Т.е. от обмена ты не уходишь, а к бардаку приводишь.

+(13) Ну а раз от обменов нам всё равно не уйти, то какая разница, передавать ИД и путь к картинке или саму картинку?
Разница в объёме только, но в современных сетях, имхо, это несущественно.

>>имхо, это несущественно
Существенно. Объемы могут быть гигабайты.

(15) Ну если вместо фотографий номенклатуры прикладывать видео 4К, то может быть.

(16) фотка со смартфона 6144х8192 пикселей весит 8 Мб.
1000 позиций номенклатуры уже 8 Гб
На каждую позицию может быть несколько фоток.
Значит если взять справочник на 10 тыс элементов и по 5 фоток на позицию, то получим 400 Гб фоток.
Кстати, видео тоже возможно

(17) Это же ни о чём. Первичная синхронизация займет, конечно, какое-то время. А потом вряд ли появляется по 10000 новой номенклатуры в день. Имхо, не тот случай, чтобы место экономить.

(18) Место и не надо экономить, но такие объёмы не надо хранить внутри базы 1С.

(19) Правильно. Хранить лучше в томах на диске. Но лучше не подключать к одним и тем же файлам две базы - возникнут ненужные коллизии.

(20) 1с-тома на дисках плохо управляются. Лучше сетевые каталоги

(18) Откуда такое предположение. Ведь предметная область неизвестна. У меня есть клиент сеть ломбардов. Больше 200 точек. Они делают несколько фото всего что сдают. В день легко по 10 - 15 тысяч фото загружается. Они конечно по максимуму пожатые в webp, файлики по 20-30 kb. Но их миллионы на сервере.

(22) "Откуда такое предположение." - Из (0).

(22) Вот именно поэтому фотки должны лежать на диске (а лучше на отдельном ресурсе), опубликованные через веб-сервер, а в базе храниться только её URL

(22) "Но их миллионы на сервере." - а как это всё бэкапится?
Миллион файлов бэкапить - это очень долго (разве что раздел целиком).

Лучше всего настроить хранение файлов на диске
В базах хранить только пути/имена
И синхронизировать их между базами стандартным образом через обмен
Для тонкого/веб клиента можно добавить публикацию на веб-сервере, чтобы файлики с него тянуло на чтение
На запись тоже не проблема если микросервис поднять, их дофига

(25) Так зачем их все бэкапить. При загрузке сразу копия на резервный сервер уходит. А оттуда по мере накопления на внешние диски раньше записывали. Сейчас не знаю. Это проблемы админов. Главный смысл в том что это же часть договора их нельзя менять у них и имена это их же хэшкод. Ну и в метаданных ID товара в 1С и номер договора. Чтобы при очень большом желании можно было найти без 1С.

(11) а некоторые, не будем говорить кто, но это был слоненок 8 - назвал меня земляным червяком

С учетом что в (0) упомянут сom-коннектор, то базы где-то на одном ресурсе

(29) Вы не учитываете историю веток от этого ника. Это ж полный беспредел с логической точки зрения. Так что там может оказаться всё, что угодно. Даже того, что не может быть (галлюцинации)

(28) У него просто стаж в айти 1 год, а у нас с вами уже под тридцать

(29) Ну как бы есть DCOM
Хотя оно с 1С не очень дружит

(32) а ещё есть выполнение запросов через веб-сервисы

Но мы же не будем боту сообщать всю нашу возможную инфраструктуру?