Убрать тип NULL #452499

При выполнении неких запросов (к примеру такого Запрос=новый Запрос; Запрос.Текст=" Результат = Запрос.Выполнить.выгрузить; ) и выгрузке результата в таблицу, начинаю смотреть типы колонок получившейся таблицы значений. 1с пишет что тип первой колонки "Строка;NULL", второй - "Булево; NULL". Каким образом можно обработать колонки что бы избавиться от NULL? С типами данных до сего момента шибко не работал, гугль тоже ничего внятного не выдал

Странно, по смыслк Null тут быть не может, если наименеование не 0 длины по крайней мере, это точно тот запрос который ты выполняешь?

судя по запросу такого не может быть

Для Каждого ТекущаяКолонка ИЗ Результат.Колонки Цикл коллеги, не значение NULL, а тип значения колонки. Вот цикл которым можно посмотреть

Получается что колонка в ТЗ - составного типа: Строки и NUlla. а мне нужно только строку сделать. Или булево.

is null

Вопрос: а зачем тебе избавляться от типа значения КОЛОНКИ? Значение в колонке, судя по запросу, все равно не будет NULL. Ну если уж очень хочется избавиться от типа null для значения колонки, то создай перед выгрузкой свою таблицу значений, определи для нее колонки с нужным типом и выгружай в нее.

Зачем ? Нул это нормально .

, Садитесь, 2. Во всех колонках ТЗ, получающейся методом "Выгрузить" имеется тип NULL, т.к. он может там быть - результат запроса не анализируется платформой.

Необходимость есть избавиться от нула, я эту таблицу гружу в СКД который создаю программно. Несовсем красивые вещи получаются когда я в режиме конструктора настроек накладываю отборы, каждый раз предлагается выбрать тип.

+гружу в смысле как набор - объект данных, получается "а- ля универсальный отчет". На входе ТЗ, на выходе отчет в компоновке

Типом поля в СКД рулить можно.

знаю, не знаю как вычленить нулл из составного типа, или вопрос по другому "как перебрать типы у переменной?" Хотя в СКД можно попробовать в ролях установить "Игнорировать NULL" в ролях

ОписаниеТипов (TypeDescription) Типы (Types) Синтаксис: Типы Возвращаемое значение: Тип: Массив. Массив значений типа Тип, состоящий из используемых типов. Описание: Получает типы, используемые в объекте.

похоже то что нужно, попробуем применить:)

Я в смысл не вникал, но NULL там быть не может, а тип может быть какой угодно, только что это меняет?

А ты проверь , всегда он присуствует.

написал такой кусок кода Проверяю, Поле.ТипЗначения - все равно содержит тип "NULL", подскажите куда копнуть дальше?

Разобрался сам, помогла вот такая конструкция    ПолеНабораДанных.ТипЗначения = Новый ОписаниеТипов(МассивТипов); Теперь в отчете компоновки, например в отборах нет необходимости каждый раз выбирать тип, если там подразумевалось поле не составного типа.

Окончательное решение:

Пипец.

Уже лучше, но все равно пипец :)

путей много. навскидку 1. сразу выгрузить в типизированную ТЗ 2. в запросе юзать ЕСТЬNULL

Для тех, кто в танке: "Во ВСЕХ колонках ТЗ, получающейся методом "Выгрузить" имеется тип NULL, т.к. он может там быть - результат запроса не анализируется платформой." ВСЕХ - это всех. Абсолютно. Без вариантов.

забыл добавить: "Живи с этим" :)

какой ужас. Точно понедельник - не Ваш выбор. Дюже много бреда из . Ситуация, что в указанном запросе вернется хоть какое-то поле с типом NULL невозможна если справочник иерархический и имеет наименование, бишь поля такие вообще есть.

так пробовал? ТипизированнаяТЗ.Загрузить(РезультатЗапрос.Выгрузить);

да ладно, умник, не нервничай ты так :)

Просто изначально чел из неправильно подошел к задаче, из-за чего и получается изврат ИМХО

Не... Нифига, кг/ам! Думать надо, а не просто по клавишам жмакать. И прав. 100 %. Курите дальше и выдыхайте почаще.

А в КЗ зачем добавил? Креатив что ли?

понедельник

Добавил не я, я состав постов пытался изменить. Изучи уже конструктор типов, а?

Откуда их сегодня столько повылезало-то? Аль не похмелились с утреца?

понедельник

Сойдет :)

Имхо так быстрее будит: ЗЫ, Defender aka LINN, ты ведешь себя как 70летний старик :)

А что поделать...

Ого как тема раздулась. А добавили в базу - потому что такой темы не было, фактически здесь обсуждается тонкая работа с типами данных. Fester Adams, может быть я и неправильно описал задачу, но она абсолютно реальная и потому...пройдите пожалуйста, в сад.