Как в запросе узнать, что реквизит ТЧ (составного типа) пустой #346988

Господа! Возникла у меня задача автозаполнения документа реализации в документе возврат от покупателя (УПП). Как одно из условий - заполнять надо только те строки, для которых этот документ не указан. Реквизит "ДокументПартии" имеет составной тип (там много всяких документов может быть). И вот победив основную задачу долго бился над такой проблемой: Как в запросе соединиться только со строчками, где этот документ не указан? Изначально предполагал, что будет достаточно ВозвратТоваровОтПокупателяТовары.ДокументПартии = НЕОПРЕДЕЛЕНО После нкоторых тестов выяснил, что в ряде документов этот реквизит действительно неопределён, но есть документы в которых в этом реквизите ВЫБРАН ТИП но НЕ ВЫБРАНО ЗНАЧЕНИЕ. И соответственно в запросе условие не срабатывает. После долгих поисков и раздумий пришёл к такой конструкции ВозвратТоваровОтПокупателяТовары.ДокументПартии = НЕОПРЕДЕЛЕНО ИЛИ ВозвратТоваровОтПокупателяТовары.ДокументПартии В (&МассивПустыхЗначений) И вот собственно вопрос, может кто-то знает более изящный способ?

ЗначениеЗаполнено(Значение) не помогает или это 8.0?

Это не в запросе.

для 8.0 в типовый есть функция ЗначениеНеЗаполнено

Ну все правильно и придумал :)

А еще в УПП есть такая функция ОбщегоНазначения.МассивПустыхЗначений

Господа! ЗначениеНеЗаполнено НЕ РАБОТАЕТ в запросе.

ВЫБРАТЬ   ТЧ.Реквизит ИЗ   ТЧ ГДЕ

Ага, пасиб. А разве Новый (Тип)  = Пустая ссылка? Т.е. равнозначны ли массивы? Для каждого ТипСсылки Из ОписаниеТипов.Типы Цикл

ТЧ.Реквизит - составного типа, там может быть и номенклатура, и договор и контрагент..

Ссылки равны между собой как их не создай

Ну если это документ, то у него всегда есть номер. В условие соединения или отбора НЕ РеквизитТипаДокумент.Номер ЕСТЬ NULL

(+12) В случае справочника это может быть код или наименование

плохой совет, т.к. будет происходить соединение со всеми возможными таблицами

+ И в случае активного использования RLS к ним ущё будут присоединяться таблицы прав, что может привести к вылету по ошибке ">256 таблиц".

Подбная методика используется в типовой ЗУП для определения заполнения реквизита ВидРасчета (он там составной).

и что? типовая не пример для подражания

Если есть ьпод рукой ЗУП - то можете сами посмотреть Документ.НачислениеЗаработнойПлатыРаботникамОрганизации модуль объекта - процедура ВыполнитьАвтозаполнение.

просто к тому, что это реально работает и, по крайней мере у меня, проблем не вызывало.

такого документа уже нет :)

тогда смотри НачислениеЗарплатыРаботникамОрганизации :)

Методика безусловно имеет право на жизнь. (Разве что я бы проверял ПометкаУдаления, т.к. она есть и у документов и у справочников). Если у тебя полные права, то проблем у тебя и не возникнет. А вот если есть ограничения на уровне записей, да ещё и по нескольким реквизитам, то на ошибку SQL по 256 таблиц нарваться очень лего при использовании таких конструкций.

хм, а что в случае с проверкой значений с массивом значений  соединения с другими таблицами будут отсутствововать? Кроме того проверяется всего 1 реквизит, где же здесь, даже с учетом RLS 256 таблиц набраться? Типа состаной реквизит в себя штук 100 включает и ограничений на просмотр его предопределенного реквизита еще штук 200?

(+23) впрочем да - соединения вроде должны отсутсвовать. Но нарваться на ограничение 256 тоже маловероятно.

сравни на NULL можно нарваться на пустую ссылку с выбраном типом но это от кривизны предшествеников

Не прокатывает, я в свое время это проверял. Только NULL любого реквизита.

ты бы отладчиком проверил - это у тебя займет ровно 3 минуты, а ты уже полдня бьешься и всех на уши поставил.

+ не к

лень писать хороший код? ну и живи с такой методикой

Что ты имеешь ввиду под "хорошим" кодом при условии рабочей RLS? Тут накладываются два минуса платформы - составной тип и RLS. Какой выход с "хорошим" кодом можешь предложить при условии минимума соединений и все в запросе?

Я не считаю методику с проверкой рееквизита на Null лучше чем проверку на вхождение в массив пустых ссылок. О чём и написал в 22. Однако совсем я эту методику исключить не могу, ибо в некоторых случаях её использование может быть оправдано. Проверка ССЫЛКИ на равенство и проверка РЕКВИЗИТА ссылки совершенно разные вещи. Пара виртуальных таблиц в запросе, плюс реквизит измерения составного типа (штук 15 составляющих), плюс RLS по трём параметрам на каждый из возможных  типов измерения - ошибка 256 практически гарантирована. Ты вместо споров попробуй, очень отрезвляет.

в чем минусы составного типа и RLS ?

При проверке реквизита элемента составного типа идёт соединение с КАЖДОЙ таблице из составного типа, к каждой такой

+ таблице присоединятеся запрос RLS, в котором также может учавствовать несколько таблиц. В итоге кажется что проверяешь 1 реквизит, а на самом деле проверяешь немеряное количество реквизитов, с немеряным количеством таблиц.

При какой проверке? Такой ВозвратТоваровОтПокупателяТовары.ДокументПартии В (&МассивПустыхЗначений)  ? Это не приводит к соединениям, даже если будет RLS у объекта на который ссылается ДокументПартии

Абсолютно согласен, поэтому эту методу и использую.

а может изменить тактику: перед записью документа партии проверять на пустое значение и записывать туда автоматом НЕОПРЕДЕЛЕНО.

Думал на эту тему. Однако это обуславливает обязательную ЗАПИСЬ документа (а при условии достаточного количества строк, процедура эта небыстрая). Кроме того, я сделал запись необязательной (через менеджер временных таблиц помещаю ТЧ объекта, а не ссылки) что гораздо удобнее. Да и перебирать строки ТЧ для поиска незаполненных - тоже не самый лучший вариант.

Неоправданная загрузка сиквела в запросах. Утяжеление в разы нагрузки на систему не говоря о требованиях и стоимости. Причем обе идеи (в такой реализации) только у 1С. Или никто раньше не додумался? Составной тип в реализации 1С - интерфейсная модель. Когда одно поле может принимать значение разных типов, но никак не баз данных. Для баз данных составной тип есть структура. Тогда нет неопределенностей какого же типа на самом деле этот реквизит и "давайте притянем все что может быть на всякий случай". РЛС - изобретение фантастичное. Имитация триггера, но без средств отладки. Комментарий в типовой конфе //что-то сработало. наверно rls А любой кодер знает как важна правильная работа триггера. В сумме эти два механизма дают потрясающий эффект. Разработчики сиквела его не предусмотрели.