Решить вспомнить SQL запросы. Но судя по всему в 1С запросы формируются как-то по своим правилам.
В общем возникла потребность из справочника вытащить данные, у справочника имеется табличная часть.
и вот проблема возникает на этапе вытаскивания данных из табличной части справочника.
В табличной части имеется список лиц. Мне нужно вытащить количество этих лиц, пытаюсь использовать COUNT, возвращается таблица значений с одним значением. А нужно чтобы возвращало именно число.
В общем возникла потребность из справочника вытащить данные, у справочника имеется табличная часть.
и вот проблема возникает на этапе вытаскивания данных из табличной части справочника.
В табличной части имеется список лиц. Мне нужно вытащить количество этих лиц, пытаюсь использовать COUNT, возвращается таблица значений с одним значением. А нужно чтобы возвращало именно число.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Вот это уже не имеет непосредственного отношения к тексту запроса. Выполнение запроса возвращает результат запроса. Чтобы из него получить значения есть 2 пути.
1. Это использовать выборку. Запрос.Выполнить().Выбрать(). Но ее нужно впоследствии обходить, чтобы получить данные.
2. Это использовать выгрузку в таблицу значений. Что я так понимаю у вас и было сделано. Запрос.Выполнить().Выгрузить(). В этой ТЗ и будут данные.
А вот чтобы сразу получить результат число (любые данные результата выполнения запроса), так не бывает.
Мне нужно вытащить количество этих лиц, пытаюсь использовать COUNT, возвращается таблица значений с одним значением. А нужно чтобы возвращало именно число.
Вот это уже не имеет непосредственного отношения к тексту запроса. Выполнение запроса возвращает результат запроса. Чтобы из него получить значения есть 2 пути.
1. Это использовать выборку. Запрос.Выполнить().Выбрать(). Но ее нужно впоследствии обходить, чтобы получить данные.
2. Это использовать выгрузку в таблицу значений. Что я так понимаю у вас и было сделано. Запрос.Выполнить().Выгрузить(). В этой ТЗ и будут данные.
А вот чтобы сразу получить результат число (любые данные результата выполнения запроса), так не бывает.
(17) Да там выяснилось что табличные части нужно кидать в конструктор отдельно, а не в составе справочника ну и связи прописывать (хотя как выяснилось и сам конструктор неплохо справляется). правда что плохо - не проконтролировать, а все ли необходимые поля были изъяты.
Просто когда мы изучали реляционные базы - нас заставляли делать уникальные числовые поля (int ID), чтобы при составлении сложного запроса не возникало проблем с поиском поля для связи.
А в базе 1с с которой сейчас работаю этим несколько пренебрегли(я так понимаю это норма). в результате чего приходится прошаривать все справочники документы и регистры на предмет полей по которым их можно между с собой сцепить. а это отдельный вид искусства.
Просто когда мы изучали реляционные базы - нас заставляли делать уникальные числовые поля (int ID), чтобы при составлении сложного запроса не возникало проблем с поиском поля для связи.
А в базе 1с с которой сейчас работаю этим несколько пренебрегли(я так понимаю это норма). в результате чего приходится прошаривать все справочники документы и регистры на предмет полей по которым их можно между с собой сцепить. а это отдельный вид искусства.
(19)
Это на каких базах так учили? mysql, sqlite ? Там да, это нормально, так как не подразумевает очень большие объемы данных. В "серьезных" sql использовать int в качестве идентификатора считается моветон. Он ограничивает количество записей в таблице разрядностью. Обычно используют guid или как в 1С - Ссылку, что в свою очередь является разновидностью guid в двоичном формате.
(19)
(20)
Я сразу указывал, "вспоминайте" что такое связь "Один ко многим". Как вас учили делать несколько таблиц связанных с одной по связи "один ко многим"? Вот "вспомните", тогда и в 1С поймете как устроено.
Просто когда мы изучали реляционные базы - нас заставляли делать уникальные числовые поля (int ID), чтобы при составлении сложного запроса не возникало проблем с поиском поля для связи.
Это на каких базах так учили? mysql, sqlite ? Там да, это нормально, так как не подразумевает очень большие объемы данных. В "серьезных" sql использовать int в качестве идентификатора считается моветон. Он ограничивает количество записей в таблице разрядностью. Обычно используют guid или как в 1С - Ссылку, что в свою очередь является разновидностью guid в двоичном формате.
(19)
А в базе 1с с которой сейчас работаю этим несколько пренебрегли(я так понимаю это норма). в результате чего приходится прошаривать все справочники документы и регистры на предмет полей по которым их можно между с собой сцепить. а это отдельный вид искусства.
(20)
сцепить по ссылке не всегда работает, поскольку ссылка - не всегда однозначно определена. А это тоже вызывает ряд вопросов
Я сразу указывал, "вспоминайте" что такое связь "Один ко многим". Как вас учили делать несколько таблиц связанных с одной по связи "один ко многим"? Вот "вспомните", тогда и в 1С поймете как устроено.
Вопрос еще один.
имеется два аналогичных запроса с разницей в одну строку условия (дата равна параметру).
Запрос идет к табличной части справочника.
Справочник и табличная часть сцеплены левым соединением
В первом запросе выводит строки с нулевым значением. (всего строк 800)
Во втором запросе отлетела все строки где количество записей равно 0.
т.е. Вместо Ссылка/Количество(ТЧ.Ссылка) Выдает Null/Null
первый запрос ГДЕ
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
Второй запрос
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
И ЛицевыеСчетаСписокЖильцов.ДатаОкончания = &ПустаяДата
имеется два аналогичных запроса с разницей в одну строку условия (дата равна параметру).
Запрос идет к табличной части справочника.
Справочник и табличная часть сцеплены левым соединением
В первом запросе выводит строки с нулевым значением. (всего строк 800)
Во втором запросе отлетела все строки где количество записей равно 0.
т.е. Вместо Ссылка/Количество(ТЧ.Ссылка) Выдает Null/Null
первый запрос ГДЕ
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
Второй запрос
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
И ЛицевыеСчетаСписокЖильцов.ДатаОкончания = &ПустаяДата
(25)
Нет. Первым запросом формируется одна таблица помещается во временную.(828 записей)
Вторым запросов из этого же регистра формируется вторая временная таблица.(620 записей)
Далее две таблицы третьим запросом сцепляются по ссылке левым соединением.
и соответственно где во второй таблице записей нет для первой, там прописывает Null и в ссылку и в значение. А нужно чтобы была ссылка и "0". Я хотел чтобы во втором запросе было тоже 828 записей но видно из-за условия часть строк убирается.
Нет. Первым запросом формируется одна таблица помещается во временную.(828 записей)
Вторым запросов из этого же регистра формируется вторая временная таблица.(620 записей)
Далее две таблицы третьим запросом сцепляются по ссылке левым соединением.
и соответственно где во второй таблице записей нет для первой, там прописывает Null и в ссылку и в значение. А нужно чтобы была ссылка и "0". Я хотел чтобы во втором запросе было тоже 828 записей но видно из-за условия часть строк убирается.
(29) Мой комментарий касался только второго запроса, псевдо-схему которого вы привели:
Учитывая, что в тексте фигурируют имена 2-х таблиц (ЛицевыеСчета и ЛицевыеСчетаСписокЖильцов), я предположил, что второй запрос строится левым соединением ТЧ СписокЖильцов к справочнику ЛицевыеСчета, поэтому и проблему я предложил решить на уровне 2-го запроса.
Второй запрос
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
И ЛицевыеСчетаСписокЖильцов.ДатаОкончания = &ПустаяДата
ГДЕ
НЕ ЛицевыеСчета.ЭтоГруппа
И НЕ ЛицевыеСчета.ПометкаУдаления
И ЛицевыеСчетаСписокЖильцов.ДатаОкончания = &ПустаяДата
Учитывая, что в тексте фигурируют имена 2-х таблиц (ЛицевыеСчета и ЛицевыеСчетаСписокЖильцов), я предположил, что второй запрос строится левым соединением ТЧ СписокЖильцов к справочнику ЛицевыеСчета, поэтому и проблему я предложил решить на уровне 2-го запроса.
(30) а если относительно ситуации с тремя запросами?
Как бы костыль ситуации я нашел:
Ссылка из первой таблицы, столбец с данными первого запроса, ЕстьNull( столбец с данными второго запроса)
Но... требуется 4-й столбец где будет сумма. и вот тут уже проблема. поскольку что угодно + нулл = нулл
Как бы костыль ситуации я нашел:
Ссылка из первой таблицы, столбец с данными первого запроса, ЕстьNull( столбец с данными второго запроса)
Но... требуется 4-й столбец где будет сумма. и вот тут уже проблема. поскольку что угодно + нулл = нулл
Правила запросов те же, разве что некоторые моменты в SQL конвертируются в три этажа. например ГДЕ А,Б в (ВЫБРАТЬ А, Б из Таблица).
Можно прямо в базе SQL по соответствующим таблицам пособирать запросы. А потом консоль запросов ( на сайте ИТС да и здесь можно любую).
Раз есть опыт SQL можно писать на 1С, потом смотреть как запрос конвертируется в SQL)
Можно прямо в базе SQL по соответствующим таблицам пособирать запросы. А потом консоль запросов ( на сайте ИТС да и здесь можно любую).
Раз есть опыт SQL можно писать на 1С, потом смотреть как запрос конвертируется в SQL)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот