В практике разработки на управляемых формах 1С программисты часто сталкиваются с загадочным поведением системы: на сервере ссылка на объект (документ или справочник) выглядит вполне «живой» и корректной, но стоит передать её на клиент или отобразить в таблице формы, как пользователь видит надпись «Объект не найден». Давайте подробно разберем, почему это происходит, как работает механизм ссылок «под капотом» платформы и какие приемы помогут гарантированно решить эту проблему.
Проанализируем фрагмент кода, который часто становится источником ошибок. Многие разработчики используют конструкцию Документы.ИмяДокумента.ПолучитьСсылку(УникальныйИдентификатор). Важно понимать: этот метод не обращается к базе данных. Он просто математически вычисляет ссылку на основе переданного GUID.
Если объекта с таким идентификатором в физической таблице базы данных не существует, метод ПолучитьСсылку() всё равно вернет объект типа ДокументСсылка. На сервере проверка такой ссылки через ЗначениеЗаполнено() вернет Истина, так как ссылка не является пустой. Однако при попытке прочитать представление этой ссылки на клиенте, система поймет, что данных в базе нет, и выдаст <Объект не найден>.
Рассмотрим, как правильно проверять существование объекта на сервере:
Вместо ненадежной проверки через Строка(Ссылка), которую мы видим в обсуждении, следует использовать запрос или попытку получения объекта. Рассмотрим пример правильного кода:
// Неправильно:
Если Найти(Строка(ЕстьСсылка), "<Объект не найден>") <> 0 Тогда ...
// Правильно (через запрос):
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Ссылка
|ИЗ
| Документ.СчетНаОплатуПоставщика
|ГДЕ
| Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", ПроверяемаяСсылка);
Результат = Запрос.Выполнить();
Если Результат.Пустой() Тогда
// Объекта в базе нет, ссылка «битая»
КонецЕсли;
Выясним причину, по которой даже после создания объекта ссылка может продолжать отображаться как битая. Платформа 1С активно использует кэширование представлений для оптимизации трафика между клиентом и сервером. Если клиентское приложение один раз «запомнило», что ссылка с данным GUID не имеет представления (т.е. объект не найден), оно может не обновлять это состояние сразу после записи объекта на сервере.
Для решения этой проблемы в управляемом интерфейсе предусмотрены специальные методы. Рассмотрим их подробнее:
ОбновитьОтображениеДанных(). Вызывается на клиенте. Он заставляет форму перечитать представления всех ссылок, отображаемых в данный момент.ОповеститьОбИзменении(Ссылка). Этот метод сообщает всем открытым формам, что данные конкретного объекта изменились, и их нужно перечитать из базы.Проанализируем ситуацию с правами доступа. Часто разработчик выполняет код на сервере в привилегированном модуле или использует команду УстановитьПривилегированныйРежим(Истина). В этом случае сервер видит объект, так как проверки прав игнорируются.
Однако, как только ссылка попадает на клиент (в реквизит формы или таблицу), в силу вступают права текущего пользователя. Если RLS (Record Level Security) запрещает пользователю чтение данного конкретного документа, платформа скроет его данные, и пользователь снова увидит «Объект не найден». При этом технически ссылка будет верной, но недоступной для визуализации.
Что нужно проверить:
RLS.Посмотрим на важный нюанс, упомянутый в сообщениях форума: если объект создается в рамках серверного вызова, он обязательно должен быть записан в базу данных. Ссылка на созданный, но не записанный объект (Объект.Ссылка), физически не существует в БД. Как только серверный вызов завершится, объект в памяти будет уничтожен, а ссылка на клиенте станет «битой».
Рассмотрим правильную последовательность действий при программном создании документов из обработки:
&НаСервере
Функция СоздатьДокументНаСервере(Данные)
НовыйДок = Документы.СчетНаОплатуПокупателю.СоздатьДокумент();
// Заполнение реквизитов
НовыйДок.Дата = ТекущаяДата();
// ...
НовыйДок.Записать(РежимЗаписиДокумента.Запись);
Возврат НовыйДок.Ссылка; // Теперь ссылка будет валидна на клиенте
КонецФункции
Проанализировав исходный код автора темы, можно заметить избыточность и использование потенциально опасных методов. Попробуем оптимизировать алгоритм поиска и передачи ссылок. Вместо огромного набора условий ИначеЕсли для каждого типа документа, лучше использовать возможности метаданных или обобщенные функции.
Пример оптимизированного поиска по УИД:
&НаСервере
Функция НайтиСсылкуПоУИД(ИмяДокумента, СтрУИД)
УИД = Новый УникальныйИдентификатор(СтрУИД);
Менеджер = Документы[ИмяДокумента];
Ссылка = Менеджер.ПолучитьСсылку(УИД);
// Проверяем реальное наличие в базе
Запрос = Новый Запрос("ВЫБРАТЬ Ссылка ИЗ Документ." + ИмяДокумента + " ГДЕ Ссылка = &Ссылка");
Запрос.УстановитьПараметр("Ссылка", Ссылка);
Если Запрос.Выполнить().Пустой() Тогда
Возврат Неопределено;
Иначе
Возврат Ссылка;
КонецЕсли;
КонецФункции
Использование ЗначениеВРеквизитФормы также требует осторожности. Если вы обновляете таблицу значений, которая является реквизитом формы, убедитесь, что типы колонок в этой таблице позволяют хранить ссылки нужных типов (проверьте Тип значения в свойствах колонки на закладке «Реквизиты»).
Если вы столкнулись с «битой» ссылкой при передаче с сервера на клиент, пройдите по следующим шагам:
Ссылка.ПолучитьОбъект() не должен возвращать Неопределено на сервере).ОбновитьОтображениеДанных().RLS.ДокументСсылка.СчетНаОплату или составной тип).Строка(Ссылка) = "<Объект не найден>", так как результат этой функции зависит от локализации платформы и прав доступа, а не от физического наличия записи в БД.Соблюдение этих правил позволит вам избежать проблем с передачей данных между контекстами управляемого приложения и обеспечит стабильную работу ваших обработок по загрузке и синхронизации данных.