Проблема следующего характера: В 1С на базе 8.3 используется механизм перевода данных(сслыки/таблицы значений) в строки с помощью ЗначениеВСтрокуВнутр(), после это сохраняется в виде строки в реквизите объекта. По необходимости из строки идет восстановление в данные ЗначениеИзСтрокиВнутр () (сслыки/таблицы значений) , но иногда возникают проблемы по имеющейся записи (ссылке) не восстанавливается ссылка на объект, имеем подобную картину <Объект не найден> (23:b6e900155d53460211e53a41a85be3a6),
<Объект не найден> (23:b6e900155d53460211e53a603c90c3c5).
т.е. 99,99% объектов сохраняются и восстанавливаются нормально, а некоторые нет, записывается в строке UUID по которому не находится ссылка на объект. Может кто-то сталкивался с подобной ситуацией ? Не понятно он сразу криво записывается или при хранении происходит сбой.

Почитай СП по ЗначениеВСтрокуВнутр() и сильно сильно расстройся

Читал:

Используется для сохранения функциональной совместимости с 1С:Предприятием 7.7. Использовать для других целей не рекомендуется.

Но механизм работает пару лет, только недавно начали возникать проблемы.

Используется для сохранения функциональной совместимости с 1С:Предприятием 7.7. Использовать для других целей не рекомендуется.
Для совместимости с 7.7. Для совместимости, Карл!

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

(0) Не рассматривал ситуацию удаления объекта?

(0) Эти объекты вы САМИ, ЛИЧНО, удалили из ИБ. Чего вы после этого хотите - непонятно.

а ведь могли заюзать версионность. в таком случае можно было бы восстановить с тем же uid'ом.... Я правда не помню, может измерение объект ведущее измерени

Расстрелять автора за такое решение.

(6) объект не удален, такое ощущение что при записи пишется ошибочный UUID, потому что при поиске объекта по битой ссылке, в бекапе то же не дает результата.

(10) а как ты ищешь в бэкапа?
Вот это <Объект не найден> (23:b6e900155d53460211e53a41a85be3a6) не ГУИД. Из него можно рассчитать гуид, но просто взять-вставить и найти в базе нельзя. Где то валялась обработка по получению гуид из такой строки вида <Объект не найден>

<Объект не найден> (23:b6e900155d53460211e53a41a85be3a6)
соответствует гуид
a85be3a6-3a41-11e5-b6e9-00155d534602

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

(13) Или же все таки каких то элементов справочников в базе вдруг начинает нехватать... Где то ты не договариваешь, товарищ... Все врут (С) House MD

(14) вроде бы все описал, но могу подробнее: есть справочник Сотрудники, и есть документ со строковым реквизитом, в этом документе табличная часть с колонкой сотрудники. Набиваются сотрудники, при записи документа табличная часть преобразуется в строку (ЗначениеВСтрокуВнутр()), записывается в строковый реквизит. И так и хранится, при открытии документа происходит обратная манипуляция из строкового реквизита идет преобразование в табличную часть (ЗначениеИзСтрокиВнутр ()). И несколько раз записанный в строку элемент не преобразуется в элемент справочника, не находит с таким иудом. Причем я знаю какой элемент был при записи и иуды разные (элемента и записанный в строке), такое впечатление что криво записывается уид.

А если преобразовывать всю тч, а строки тч в цикле?

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