Доброго дня всем!
Имеется такая проблема: получение даты из ссылки на документ (через Ссылка.Дата) очень медленное. При этом другие "реквизиты" ссылки (например Номер, СуммаДокумента) получаются в несколько десятков раз быстрее.
Можно ли от этого избавиться?

Понятно... Да, я знаю, что в запросах нужно брать все нужные реквизиты. Только этот документ у меня берется из строки с уникальным идентификатором, а не из запроса, поэтому наверное здесь ничего не придумать быстрее.

Last1CmenAXAE, а выборка этих строк по-одной или как-то можно их распарсить перед запросом и передать уже в запрос номера списком ?
Подробнее?
У меня действительно есть список строк с уникальными идентификаторами... Каким образом их распарсить и в запрос передать?

Last1CmenAXAE, я так понял что речь о 8ке... с синтаксисом запроса я не помогу

автордокумент у меня берется из строки с уникальным идентификатором

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

правда это не касается того варианта если у вас есть не один или несколько документов для вывода т.к. как сами понимаете процедура выполнения запроса будет несколько медленнее чем одиночное получение ссылки... так что смысл будет когда количество получений объектов по ссылкам в цикле по временным характеристикам будет превышать время одноразового выполнения запроса (скажем более сотни таких объекто должно реально ускорить)


для того чтобы вам ответили как именно распарсить строку с ИД необходимо предоставить сами примеры строк и то что должно быть из них выделено и сопоставлено в сравнении

По-моему, их никак не распарсить... GUID - это результат применения метода УникальныйИдентификатор() к ссылке. Например вот GUID - "2319dcf1-f4ee-438d-b16f-6a145d6b9422". Уникальные идентификаторы в запрос "восьмерки" не передать. Можно передавать только ссылки. На основе уникального идентификатора можно получить любую(!) ссылку.

HoBTIDAXAEПо-моему, их никак не распарсить... GUID - это результат применения метода УникальныйИдентификатор() к ссылке. Например вот GUID - "2319dcf1-f4ee-438d-b16f-6a145d6b9422". Уникальные идентификаторы в запрос "восьмерки" не передать. Можно передавать только ссылки. На основе уникального идентификатора можно получить любую(!) ссылку.
Идея Last1Cmen - получить реквизиты сразу всех документов одним запросом, а не таскать каждый в цикле по ссылке. И это будет быстрее, если документов хотя бы 2, а если, например, не нужны табличные части, то будет быстрее даже при одном документе.
Идея понятна... Только на восьмерке ее не осуществить: на основании списка строк с GUID'ами не удастся получить список ссылок с реквизитами. Точнее удастся, но только если запрос формировать так, чтобы пробовать запросом одновременно вынимать ссылки на основании уникального идентификатора из всех ссылочных типов конфигурации - а это по-моему будет медленно.

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

Last1Cmen...возвращать в запрос уже саму ссылку и по ней фильтровать... Заметьте: не одну ссылку, а ссылки ВСЕХ ссылочных типов конфигурации, полученных на основании одно единственного GUID! А если этих GUID еще и целый список (у меня их десятки тысяч), то я думаю можно представить, как захлебнется 1С...

Да вообще-то не каждый день... Это нерегулярная процедура. Это процедура проверки. Конфигурация Альфа-Авто использует таблицу соответствия для переноса информации в бухгалтерию. Таблица соответствия представляет собой .dbf файл, где есть поля ID_SOURCE, ID_RECEVE и MANAGER. В первых двух полях хранятся GUID объектов: Альфа-Авто и Бухгалтерии соответственно. В них хранятся GUID документов и справочников. Поле MANAGER предназначается для описания менеджера бухгалтерии (вроде бы так... я его при обработке таблицы мало использую)
Мне необходимо проверить правильность этой таблицы. Мы ее своими кривыми ручками подпортили - залезли посмотреть, решили удалить несуществующие объекты. Удалили и не переиндексировали. При очередном переносе случился сбой и таблица была немного испорчена.
Да бывают и штатные ситуации, когда два контрагента Альфы грузятся в одного в бухгалтерии - такое тоже надо разыскивать и пресекать. Пресекать - это здесь уже дело десятое... Главное - найти таких.
Я вроде нашел решение своей проблемы: я перебираю последовательно все ссылочные типы конфигурации, создаю на основании GUID ссылку разных типов и проверяю на существовании такого объекта. Проверка осуществляется запросом к базе с параметром как раз этой сгенерированной ссылки. В этом запросе ведь можно сразу получать и реквизиты объекта, если он существует... А для того, чтобы это работало побыстрее, чем перебор всех ссылочных типов - предусмотрен, скажем так, "кэш попаданий". Там накапливаются количества верно угаданных типов ссылок.