Так а что здесь возвращается?

С вами? Боже упаси. Вопросов больше нет. Извините.

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


И разве ж это "легче работать и обслуживать"?


А как БСП справляется, например, с доступом к внешнему каталогу файлов, в зависимости от RLS или каких-то настроек, типа "Васе можно редактировать картинки из группы Крупы, а Пете из группы Овощи"? Ответ

Никак. БСП может контролировать что-то для доступка к справочнику с номенклатурой, но никак не к внешней папке на диске

Если что, то файл транзакций не всегда как бы есть. Точнее говоря, он может быть есть всегда, но при правильной модели восстановления его размер не растет. В мире 1С (та и не в мире 1С) это очень редкие случаи, когда действительно надо иметь файл транзакций. Это штука, про которую кто-то где-то слышал, но мало кто понимает что это, зачем и как этим пользоваться. Но на всякий случай "хай буде". Если у вас БД на 10-20 Гб, я очень сильно сомневаюсь, что вам это надо. И последнее. Бинарные данные в лог не пишутся как есть, там они пишутся в специальном каком-то формате, что означает, что картинка на 1 Мб это не +1 Мб в лог транзакций.

Со своего опыта вы можете сказать зачем вам БД с пишушимся файлом транзакций? Чтобы что? Только не из теоретической плоскости, а из практической, желательно с примером того, какую проблему вы решили этим.


Т.е. проведение документов тупило, отчеты тупили, а потом после удаления картинок, перестали тупить? Вам самому это не странно звучит?


Это один из немногих сценариев, когда вынесение файлов отдельно можно рассматривать как то, что надо. Но только при условии, что файлы не страшно потерять. Если файлы - это важная часть данных (например, договора), то я бы лучше мирился с бОльшими архивами и бОльшим временем на обработку бекапов, чем отдельно думать о бекапах и разных прочих штуках с папкой.

Что вы вкладываете в понятие "легче с ней работать и ее обслуживать"? И не надо ли вам как-то обслуживать каталог с картинками: настроить доступ с разных устройств (если вы работаете через тонкий клиент в браузере с разных регионов, как папку нормально пошарить между всеми?), настроить какие-никакие права (чтобы кто-то не зашел и не поудалял там все), бекапить и т.п.?


Какая связь между "дублированием сущностей" и "несколько ГБ" места в БД? Картинки в БД это дубли чего?

Вы выше писали:

А какие проблемы с этим были?

Я не докапываюсь, мне дейсвительно интересно послушать мнения на этот счет.

Какие проблемы это создает?

Ну не хотят и не хотят. Их право.

Так и почему вам ничего не подошло оттуда?
На самом деле это просто мало кому вообще надо.

Ладно, вот держите.

Автор этой штуки вроде пользуется обфускатором. Можете у него поинтересоваться.

Просто пишите уйню

Так а как сделали в итоге?

kuzma2000, а если писать строку в кодировке ANSI?

Только что быстренько нагуглил такое:

ЗТ = Новый ЗаписьТекста(ИмяФайла, КодировкаТекста.ANSI);
ЗТ.Закрыть();
ЗТ = Новый ЗаписьТекста(ИмяФайла,,, Истина, Символы.ПС);
ЗТ.Записать(Данные);
ЗТ.Закрыть();

Тут человек сначала записывает пустой файл в кодировке ANSI, потом туда дописывает что надо в кодировке UTF-8. Это может не совсем прям то, что вам надо (т.к. тут создается файл на диске), но если другого варианта не найдете, можете попробовать это прогонять таким образом через временный файл и потом файл удалять.

А скриншот это откуда?
Попробуйте сохранить ваш XML в файл на диске и посмотреть есть ли там эти символы.

Беручи до уваги

створіть нову базу і завантажте туди актуальну копію.

В последних типовых конфигурациях, если мне не изменяет память, сотни ролей. Технически оно работает. Но управлять этим всем - это ад. На мой взгляд, такого вида решение не жизнеспособно по другим причинам. Когда мы говорим про чтение или запись, обычно это означает чтение или запись не только одного объекта, а и других связанных объектов, например, регистров. И надо держать в голове, что "если давать доступ на справочник А, то надо дать доступ на регистр сведений Б". С документами, какими-то отчетами и обработками будет еще сложнее.

Если вы опишете что именно вы делаете, какую именно ошибку получаете, у вас будет больше шансов получить какой-то ответ.

В 8 есть метод ПодключитьОбработчикОжидания() или что-то типа этого. Там, кажется, указывается процедура которую надо вызвать, интервал через когда вызвать, и еще что-то. Короче точно не помню, но суть должна быть понятна. В 7.7 я вообще ничего уже не помню, но быстренько загуглил, вроде как там тоже есть метод ОбработкаОжидания(). Я бы смотрел в эту сторону. Т.е. открыть форму, а в ПриОткрытии вконце добавить обработчик ожидания, который выведет лог.

Просто у меня ощущение, что на самом деле они хотят что-то другое, т.к. 2 позиции с полностью одинаковыми атрибутами в документе (характеристика, серия, цена, заказ и т.п.) с точки зрения учета всеравно "схлопнутся" в одну в итоге.

У вас в заказе одна и та же позиция номенклатуры с одной и той же ценой может встречаться в нескольких строках? А зачем, если не секрет?

Это не стандартная обработка, а часть подсистемы Инструменты разработчика. Первая строка в гугле по запросу "1с инструмены разработчика".

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


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

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

Формат yyyy-MM-dd - это дата вида год-месяц-день, начало дня. Вы выбираете данные из регистра на момент времени условно 20.02.2025 00:00:00. Но другой момент еще в том, что если вам нужен остаток, то выбирайте данные из виртуальной таблицы Остатков регистра. Ну и на конец дня, а не на начало.