Доброго времени суток.

Допустим на каком-то этапе запроса имеем таблицу с 2 колонками "Тип" (строка) и "Коэф" (число)

Тип   | Коэф
------|-------
Тип1  |   5
Тип2  |   1
Тип3  |   10

Нужно перемножить числа из колонки "Коэф" данной таблицы и вывести итоговый результат. Т.е. по примеру выше должно быть выведено "50"

Вопрос - как это сделать исключительно средствами запроса?

Пока в голову приходят только решения с промежуточной обработкой результата.

Ограничения на коэффициенты какое-нибудь есть? Типа "целое и диапазона"?

А в самом деле, почему нет такой функции...
http://www.sql-tutorial.ru/ru/book_product_of_column_values.html

(2) Зато тангенсы есть...

Сейчас не взлетит. Но обещают логарифм и экспоненту завести. Тогда можно с ними через сумму.

https://wonderland.v8.1c.ru/blog/novye-funktsii-yazyka-zaprosov-i-sistemy-komponovki-dannykh/

А вообще произведение будет погрешность большую давать

(4) ещё немного и будет нам T-SQL =)

произведения в колонке - такого даже в самом скл нет

(4) > Сейчас не взлетит.

Чой-та?
Если как следует заипацо и разложить ln и exp в какой-нибудь ряд Тейлора до приемлимой точности, то вполне.

(1) Дробные числа - 12,2

(4)(6) Мне сейчас надо.

Пока видится только вариант - выгрузить результат запроса (это СКД) в таблицу, обойти и вычислить произведение коэффичиентов, а потом результат загрузить обратно в СКД (в другйо макет) и уже через него сделать вывод в табличный документ

(9) > это СКД
А говорил, что в запросе...
RTFM, наверно, https://infostart.ru/1c/articles/1116759/ в части "ГрупповаяОбработка"

(9) интересно накуа?

(0) Произведение коэффициентов?
Произведение может приводить к переполнению разрядности поля если числа, которые необходимо умножить хотя бы двузначные и таких чисел в по количеству 10-20 штук.

Если принять что коэффициентов, которые тебе необходимо перемножать не более 10 строк по каждому виду, то можно ИЗВРАТИТЬСЯ и сделать как ниже, НО лучше так НЕ делать.
SQL в 1С очень убогий, поэтому приходится извращаться, что бы не использовать "SELECT exp(SUM(log(value)))..." с учетом отрицательных чисел и null.
Оконных функций нет и АВТОНОМЕРЗАПИСИ() при сортировке можно использовать только при "ВЫБРАТЬ ПЕРВЫЕ МНОГО". Поэтому такой ужасссс ниже и ограничение в использовании!!!!
Если будет 11 строк по коэффициенту, то будет неверный результат умножения.

ВЫБРАТЬ
    1 КАК Коэф,
    10 КАК Сумма
ПОМЕСТИТЬ ВТ_Данные

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    1,
    2

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    1,
    2

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    1,
    -4

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    1,
    5

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    2,
    -2

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    2,
    3

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    2,
    -5
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ ПЕРВЫЕ 1316134911
    ВТ_Данные.Коэф КАК Коэф,
    ВТ_Данные.Сумма КАК Сумма,
    АВТОНОМЕРЗАПИСИ() КАК нпп
ПОМЕСТИТЬ ВТ_ДанныеСорт
ИЗ
    ВТ_Данные КАК ВТ_Данные

УПОРЯДОЧИТЬ ПО
    Коэф,
    Сумма
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    т1.Коэф КАК Коэф,
    т1.Сумма КАК Сумма,
    т1.нпп - т2.нпп + 1 КАК НПП
ПОМЕСТИТЬ ВТ_Данные_НПП
ИЗ
    ВТ_ДанныеСорт КАК т1
        ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            т.Коэф КАК Коэф,
            МИНИМУМ(т.нпп) КАК нпп
        ИЗ
            ВТ_ДанныеСорт КАК т
        
        СГРУППИРОВАТЬ ПО
            т.Коэф) КАК т2
        ПО т1.Коэф = т2.Коэф
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    т.Коэф КАК Коэф,
    ЕСТЬNULL(т.Мн1, 1) * ЕСТЬNULL(т.Мн2, 1) * ЕСТЬNULL(т.Мн3, 1) * ЕСТЬNULL(т.Мн4, 1) * ЕСТЬNULL(т.Мн5, 1) * ЕСТЬNULL(т.Мн6, 1) * ЕСТЬNULL(т.Мн7, 1) * ЕСТЬNULL(т.Мн8, 1) * ЕСТЬNULL(т.Мн9, 1) * ЕСТЬNULL(т.Мн10, 1) КАК ПроизведениеМаксДесятиСтрок,
    т.Мн1 КАК Мн1,
    т.Мн2 КАК Мн2,
    т.Мн3 КАК Мн3,
    т.Мн4 КАК Мн4,
    т.Мн5 КАК Мн5,
    т.Мн6 КАК Мн6,
    т.Мн7 КАК Мн7,
    т.Мн8 КАК Мн8,
    т.Мн9 КАК Мн9,
    т.Мн10 КАК Мн10
ИЗ
    (ВЫБРАТЬ
        т.Коэф КАК Коэф,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 1
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн1,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 2
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн2,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 3
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн3,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 4
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн4,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 5
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн5,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 6
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн6,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 7
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн7,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 8
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн8,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 9
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн9,
        МАКСИМУМ(ВЫБОР
                КОГДА т.НПП = 10
                    ТОГДА т.Сумма
                ИНАЧЕ NULL
            КОНЕЦ) КАК Мн10
    ИЗ
        ВТ_Данные_НПП КАК т
    
    СГРУППИРОВАТЬ ПО
        т.Коэф) КАК т

Максимально в подзапросы для читабельности. Можно было этим не заниматься, но не для себя же писал, а что бы (0) смог разобраться.

(2) В книге-статье по ссылке говориться, что автор не знает есть ли SQL сервер, который поддерживает агрегатную функцию умножения.
Точно есть. Я с таким сталкивался лет 15 назад - название сервера не помню уже. Какой-то экзотический.

Умножение коэффициентов из задач про бухгалтерию на вскидку вспомнил только одну. Это расчет среднего для отпуска при нескольких повышениях ЗП в расчетном периоде. Оклад в этом случае умножался на все коэффициенты повышения оклада после периода начисления оклада и до окончания расчетного периода (бывает повышение и после окончания расчетного периода, но до начала отпуска).
Сейчас средний уже несколько иначе считается. Но когда-то было и так в том числе.
А так больше не приходилось сталкиваться.

(0) Кстати есть ещё один извращенский способ :-)
Номер Значение
1      -2
2       4
3     3.3
4    -0.1
...
N     0.8

То же есть ограничение, но суть в том что бы умножать первую и вторую строку, третью и четвертую, пятую и шестую. Полученный результат заново нумеровать и повторять. Повторив так десять раз получим 2 в десятой = 1024 строки. Т.е. ограничение не десять, умножаемых строк, а целых 1024.
Но это тоже ИЗВРАТ :-)

+ к (15) Если применить не к числам, а к строкам и не умножение, а конкатенацию, то можно складывать последовательно строки.
Так например регулярных выражений в SQL 1С нет, а иногда немного надо. Разбираем посимвольно строки, что-то делаем и собираем обратно. :-) Не всё можно сделать, но что-то можно. Например удалить из строки все символы из списка.
Работает не долго, при не больших объемах данных.

(12) Все это баловство, вот где правда -> (4)

(14) У меня тоже, более чем за 10 лет, ни разу такой потребности не вставало, а тут "НАДО". Зачем - объяснять не вижу смысла.

Предложенные варианты конечно тот еще изврат.

Попробую вариант в (10)

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

(19) В варианте с промежуточной таблицей тоже есть минусы - получается нужно 2 макета СКД - один под первую выборку и выгрузку в ТЗ, а второй под финальный вывод в табличный документ. При этом нужно сохранить возможность изменения структуры отчета и возможность отборов (в пользовательском режиме), а это значит накладывать отборы нужно первый макет, а настраивать структуры по второму. Нечто подобное я уже реализовывал, но это тоже "гемор" и определенные ограничения.

Короче в СКД можно так ресурсу сделать: ВычислитьВыражение("Exp(Сумма(Log(Значение)))")
У меня заработало, правда округление дикое

(18) И правильно. Я показал ИЗВРАТ, что бы в эту сторону поползновений не было. А то будешь искать варианты там где их нет. :-)
Да и условие странное, всё только языком запросов 1С, при условии, что язык запросов в 1С ооооочень сильно обрезан, по сравнению с тем, что поддерживают SQL-сервера.

Почему всё так плохо? Вся причина в файловой. Тянут этот прицеп - цена вопроса потеря функциональности.

(19) Не предлагал, а мягко показал, что вариант есть, но он настолько плохой, что его использовать не стоит. И несколько раз прямо об этом сказал и КРУПНО :-)

P.S.
Пора делать 9-ку без файловой :-) Продавать её принципиально по другому. Не нравится конфигуратор - в топку его. и т.д. Напробовали разных вариантов в 8.0, 8.1, 8.3 - пора что-то конечное делать.

В СКД можно через функцию общего модуля выкрутиться в формуле ресурса.

(21) Попробую. Спасибо.

(21) Встречал ещё такой вариант:
Oracle : EXP(SUM(LN(column)))   or  POWER(N,SUM(LOG(column, N)))
MSSQL  : EXP(SUM(LOG(column)))  or  POWER(N,SUM(LOG(column)/LOG(N)))
MySQL  : EXP(SUM(LOG(column)))  or  POW(N,SUM(LOG(N,column)))

(17) Понятно что баловство, но ждать пока будет реализовано в (4) можно и до китайской пасхи, а (0) нужно вчера.
То что заявлено, что будет реализовано, не факт что будет.

Опять же сделают эти функции и добавят кучу ограничений. "АВТОНОМЕРЗАПИСИ()" уже добавили и что - сильно всем помогает?
Зачем вводить ограничение использовать только во внутренних таблицах?
Зачем вводить возможность сортировки таких внутренних таблиц с "АВТОНОМЕРЗАПИСИ()" только если указано "ВЫБРАТЬ ПЕРВЫЕ N"?
Откуда они придумывают такие ограничения? Опять файловая? В топку файловую.

(26) >>> АВТОНОМЕРЗАПИСИ

Да ни черта, о ней еще надо вспомнить.
Вот если допилят до (4), а еще если позволят условия в запросах выставлять более гибко, как в SQL.
Вот тогда и будет народ пользоваться.

Ну а если они еще и функции позволят писать, для запросов, то вообще будет суперски :)

(21) Медленно.

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

(29) Соединение нужно только одно, и то только из-за того что нельзя нумеровать список по группировкам. Пример в (12) как раз без соединений. Каждое соединение это убийца производительности. Чем меньше джоинов, тем быстрее выполняется запрос.

(28) Конечно медленно. Это же обработка результата запроса уже не средствами SQL. Расчет для каждой строки проходит как отдельный вызов.

(29) Почему длины числа не хватит? А если коэффициенты вот такие:
1,2
0,8
0,87
1,11
1,02
0,98
0,65
0,95
1,22
1,15

Другими словами "болтаются" около единицы и их произведение стремиться к 1.

(19) "и через месяц не вспомнишь - что это за ахинея"

С ахинеей согласен на 100%.

С тем что не вспомнишь НЕ согласен. Запрос слишком прост, чтобы за минуту другую не понять, а тем более вспомнить что он делает.

+ (32)

1) ПОМЕСТИТЬ ВТ_Данные - это генерация самих данных. Запрос может быть любой и данные тоже.
2) ПОМЕСТИТЬ ВТ_ДанныеСорт - это добавление общей нумерации в поле НПП, но в обязательном порядке группировки по полю "Коэф", по сумме не обязательно.
3) ПОМЕСТИТЬ ВТ_Данные_НПП - это перенумерация таким образом, что бы для каждой группировки нумерация шла с 1.
Последний запрос добавляет поля - сколько необходимо 10, 15, 20... ещё ужаснее маразм :-) ... 100 При этом значение поля будет установлено в сумму только где номер по порядку суммы совпадает с номером колонки, в остальных случаях NULL. Разворачивание таблицы (нет PIVOT и UNPIVOT в 1С тем более). Далее МАХ() сворачивает таблицу так что по каждой группировке остается одна строка и много добавленных колонок. При этом NULL всегда меньше любого значения. Собственно поэтому NULL, а не кое-то число.
Далее приведение итоговый значений в свернутой таблице если они NULL к 1 и умножение колонок.

2) и 3) аналогичны одной записи "ROW_NUMBER() OVER(PARTITION BY Коэф ORDER BY Сумма)", но 1С так не позволяет. Оконных функций нет в 1С.

2) Коэф, сумма, НПП
1, 1, 1
1, 2, 2
1, 2, 3
1, 4, 4
2, 1, 5
2, 2, 6
2, 2, 7

2) Коэф, сумма, НПП
1, 1, 1
1, 2, 2
1, 2, 3
1, 4, 4
2, 1, 1 нумерация опять с 1
2, 2, 2
2, 2, 3

3) Коэф, сумма, НПП, мн1, мн2, мн3, мн4, мн5,...
1, 1, 1, 1, NULL, NULL, NULL, NULL,...
1, 2, 2, NULL, 2, NULL, NULL, NULL,...
1, 2, 3, NULL, NULL, 2, NULL, NULL,...
1, 4, 4, NULL, NULL, NULL, 4, NULL,...
2, 1, 1, 1, NULL, NULL, NULL, NULL,...
2, 2, 2, NULL, 2, NULL, NULL, NULL,...
2, 2, 3, NULL, NULL, 3, NULL, NULL,...

после сворачивания
Коэф, мн1, мн2, мн3, мн4, мн5,...
1, 1, 2, 2, 4, NULL,...
2, 1, 2, 3, NULL, NULL,...

После ЕСТЬNULL()
1, 1, 2, 2, 4, 1,...
2, 1, 2, 3, 1, 1,...

(19) теперь ахинею не забыть :-)

(24) Ты задачей-то поделись, где нужно умножение. Интересно же.

И почему непременно в запросе.

(35) Скорее всего там этого и не нужно. Или можно решить как-то иначе. Мне на вскидку пришла на ум только задача в (14).
Но в ней количество коэффициентов, которые необходимо умножить редко бывает более 1. Очень редко ЗП поднимают по всему предприятию или подразделениям более одного раза в 12 месяцев.
Её вообще редко поднимают группе сотрудников :-). Чаще увольняются сотрудники, а принимают новых уже на других условиях других сотрудников. ОК не мониторят среднюю ЗП постоянно, а делают это только когда вакансию не могут закрыть и ищут обоснования. А можно было бы в 90% и прошлых сотрудников сохранить, учить не надо, вникать не надо и т.д. :-) Но это уже совсем другая история....

(35) Состав изделия, где есть коэффициенты запуска (вероятность получения годного). Расчет затрат в ЖКХ, где сумма произведений и коэффициенты зависимости от типа строения и коммуникаций для оценки ремонта. В страховании есть такое. Даже симптоматику учитывать в медицине можно по влиянию на диагноз. Очень много прогнозных вещей есть в статистике с произведением строк, да и при контроле качества тоже. Это то, что вспомнилось за овер 30 лет работы.

(37) Да, на оракле можно было сделать собственные команды и применять их в запросах. 15 лет назад это делал, уже забыл вроде CREATE COMMAND и там описание.

(37) т.е. это все отрасли, где 1С не поможет, так как нет в запросах математических функций.
Т.е. 1С не применимо/ограничено применимо в таких отраслях как: Производство сложных устройств и механизмов, ЖКХ в части оценки затрат, Страхование, Медицина в части оценки симптоматики (то что сейчас как раз министерство здравоохранения хочет применить как помощь врачам при определении диагнозов - выдавать список возможных и вероятность + что допроверять, что бы что-то исключить или подтвердить).

Наверняка сюда можно будет добавить любую отрасль, где нужна статистика. Например образование.

Почему неприменимо и ограниченно применимо? На малых данных можно извращаться с получением результата запроса в ТЗ, обработка на алгоритмическом языке интерпретаторе результата. Засовыванием результата опять в менеджер временных таблиц. Запрос и ещё одно левое соединение и т.д.
На больших объемах это может оказаться очень долгим процессом. А на очень больших объемах в промежуточную ТЗ результат не засунуть - места не хватит. А SQL бы "схавал".

Повторюсь. Файловую версию в топку, она реально мешает ограничивая функциональность. Зачем тянуть этот разодранный мертвый хвост.

(38) CREATE OPERATOR :)
Ораклоидам привет!

> Зачем тянуть этот разодранный мертвый хвост.

Посчитай, сколько денег с пользователей, которые на ней сидят, и поймешь.

(41) Этим пользователям можно было предложить и серверный вариант. И специальную лицензию придумать и всё это по той же цене. Так что деньги тут не при чем совсем.

(41) Серверную, например = Постгри + Сервер 1С + спец лицензия.

(43)  "и всё это по той же цене", ага
И еще админа бесплатного выделить, пожизненно, чтобы следил за всем этим, не?

(44) За чем следил? За чем в серверной так надо следить и не надо следить на серверной?

(44) За чем следил? За чем в серверной так надо следить и не надо следить на ФАЙЛОВОЙ?

(44) Так про что речь?

Максимум(Выбор когда Тип=&тип1 тогда Коэфф  конец)*Максимум(Выбор когда Тип=&тип2 тогда Коэфф  конец)

(48) В (12) по сути это уже написано, с подзапросами, что бы было понятнее, но можно без них.

(49) там какая то жесть написана, в которой я даже не стал разбираться.

(50) Да тоже самое там, только для большего количества множителей + вместо типа (Тип=&тип1) номер множителя и без лишних параметров.

НПП - это и есть номер множителя по порядку, для каждого Коэф.

(44) Так о каких действиях админа идет речь?

(44) Ну на ум приходит только - перегрузить сервер. Ночью перегрузить принудительно, но кто на файловой работает, те вообще выключают на ночь.
Архивные копии средствами SQL создаются быстрее, да и проще организационно. Не пойму, о чем идет речь, хоть убей. Не могу вспомнить. Административными делами практически не занимался, но и не помню ничего такого.
Может кто подскажет?

Ну один раз после создания базы настраивается журналирование на минимальное, что бы база не росла как на дрожжах. Но для мелких баз, которые взамен файловых это не должно быть на столько критичным.
Архивные копии - обычный скрипт средствами SQL ежедневная с глубиной архива неделя + иногда понедельная с глубиной месяц-два + ручные архивы. Опять же это просто использование готового инструмента, который 1С не составит труда сделать юзибилити.

(55) > который 1С не составит труда сделать юзибилити.
Ну вот, ты уже нашел для себя паттерн ответа. Представь себе любой ответ и примени его.

(56) Не понял я ответа. Чего там куда принять?

(56) Если бросить все силы с разработки файловой на разработку мааааааленького, но очень полезного инструмента для нескольких действий на уровне пользователя, то не хватит чего?
Разработка платформы для поддержки файловой версии несоизмеримо больше, чем мааааааленький инструмент. Это же очевидно.
В чем Вы там ответ увидели.

(60) На разработку файловой базы много сил не тратится. Новых фичей не добавляется. Только на исправление багов, редкие оптимизации и регрессионное тестирование.

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

(61) "де" = "же"

(61) Я не понимаю зачем было файловую делать изначально. Изначально тратилось сил дофига. Все новшества что делают, делают и в файловой версии в том числе. В большинстве случаев, все эти новшества просто в распознавание синтаксиса и работа так же как и раньше, но это всё равно изменения.
Сделали изначально файловую - хрен с ней.

В 8.1, 8.2, 8.3, 8.4, 8.х,.... 9.х можно было делать и без файловой.

(61) "И все это непонятно ради чего." - как раз понятно ради чего. Не развивается язык SQL в 1С из-за того, что это всё счастье необходимо реализовывать на файловой версии.
Планируют математические функции добавить в следующем релизе 8.3. Их добавлять не долго в серверной версии, так как SQL сервера их поддерживают и синтаксис практически идентичный, а в файловой необходимо всё это реализовать. Ручками.
А теперь прикинь приблизительно, сколько нам ждать тех же оконных функций в SQL. И ждать ли вообще.
Да даже ROW_NUMBER() в нормальном виде сколько ждать? АвтономерЗаписи() - это не аналог, так как у него есть не понятные ограничения использования в обязательном "select top XXX", "order by" и обязательно использование только во внутренних таблицах. Сервера SQL таких ограничений не предъявляют, значит это файловая. Больше не кому.

(63) >Я не понимаю зачем было файловую делать изначально.

Вопрос риторический или ты лукавишь?

Ну ладно, объясню. Файловый вариант работы нужен для того, чтобы охватить определенную часть рынка, где 1С могла успешно конкурировать. "Взрослые" клиент-серверные СУБД туда никак не вписывались ни по стоимости лицензий, ни по наличию квалифицированного персонала для их обслуживания. MSSQL тогда еще не достиг уровня, когда его можно поставить и забыть на долгое время. Бесплатный PostgreSQL был еще в таком состоянии, что его и с админами в критичный прод стремно было ставить.

Вот ты представь то время, все сидят на семерке и особо не страдают. 1С выкатывает 8.0 и говорит: давайте, переходите, но учтите, что файловой больше не будет, раскошеливайтесь на SQL лицензии.

Если бы 1С так сделала, это было бы самоубийство. Ты бы сейчас не ел свой хлеб с маслом.

Однако большинство баз в 1с как раз файловые, то бишь уровень ларька

Сервер можно и бесплатный было сделать. Допустим до 5 юзеров.
И возможно это было бы даже выгоднее ибо сколько человеколет разработки съэкономили бы

(65) С тех пор воды уже утекло много - это 2004-2005 года.
Я в (63) согласился, что сделали файловую и хрен с ней. Сейчас зачем тянуть этот разодранный мертвый хвост? Нельзя поставить бесплатный PostgreSQL? Нельзя предложить свою спец лицензию на своё ПО в виде сервера 1С в замен файловой? Как давно можно было это предложить?

(68) это нужно будет заставить всех переходить на скл. Очень не простое решение

(68) наверно ответ на это "так исторически сложилось"

(65) И 8.0 я сознательно не указал. Начал с 8.1, можно было бы и с 8.2
Всё равно на сейчас уже лет как 10 можно было бы предложить отказаться от файловой в замен на серверный вариант и спец. лицензией, но этого не происходит.
От этого выигрывают все. И пользователи получают более производительный вариант, как это 1С позиционирует. И 1С освобождает свои ресурсы с поддержки файловой и повышает производительность, так как нет больше файловой.

(70) Хрен с уже с этой историей - сейчас есть планы 8.4 в которых файловая присутствует или есть такой отказ от фаловой?

(68) Воды утекло много, но ситуация не сильно изменилась. Файловая и сегодня надежнее любого скуля без присмотра. И как правильно заметил (66), файловых баз большинство. Не знаю, как в плане дохода с этих пользователей, может и меньше 50%, но им точно пренебречь нельзя.

Вот если перетянуть их всех в облако, тогда можно вернуться к вопросу.

Я ни разу не слышал, что бы это вообще в планах 1С было. Зато рюшечки какие-то не нужные никому постоянно....

8.4 скорее всего не будет. Сразу 8.5 минимум

(73) Им не нужно облако - "Хочу свое под боком".

(75) Или не будет совсем.

(76) А без облака нет простого и надежного решения. Даже если подарить всем им лицензию на сервер мини, кто это все переустановит и перенастроит? 1С должна еще франчам заплатить за эту миграцию?

(78) Переустановит что?
Пока ничего 1С не предложило и по всей видимости не предложит.

Какая миграция - выгрузить базу и загрузить стандартными средствами, которые есть и как раз необходимы для переноса базы с сервера на сервер или из файловой на сервер или с сервера в файловую.
Нет тут миграции.

Пользователи не смогут установить сервер, если по умолчанию будет всё хорошо + простой и понятный инструмент для частых операций - настройка архивных копий и т.д.? Вы очень недооцениваете пользователей.
Когда была 1С 6.0 очень большая часть бухгалтеров печатные формы настраивали себе сами и без программистов.

Вопрос сложности инструмента. С выходом 7.0, 7.5, 7.7 некоторые бухгалтера уже не смогли самостоятельно настроить формы. Инструмент усложнился.
С выходом 8.х уже программисты на той же мисте - т.е. тут спрашивают, а как теперь подключить внешние печатные формы. Чего там где прописать, какие экспортные функции должны быть... И т.д. Инструмент стал ещё сложнее - правда на пустом месте в данном случае на мой взгляд. Но это моё мнение. Но по факту пользователи уже не могут разработать себе печатную форму, так как инструмент ещё усложнился.

По факту же бухгалтера как сдавали баланс и прочую отчетность, так и сдают в том числе из 1С 7.7 и даже из 1С 6.0. Если бы была поддержка этих версий, то делали бы это на много легче чем сейчас :-)

Да ПО должно развиваться спору нет, но вопрос куда и как. Сейчас всё одна задача :-) как с сервера на клиент и обратно что-то и как-то передать и особенно ТЗ. :-) Сколько при этом необходимо манипуляций и каких совершать. Синхронные и асинхронные вызовы и т.д. (собрал часть последних темы и часто обсуждаемые тут же на мисте ....).

А по факту ПО могло бы работать на порядок быстрее если отказаться от файловой и чуть докрутить SQL. Такие запросы SQL как в 1С уже давно никто не пишет. Это же архаизм какой-то, который при этом и на много медленнее работает (иногда разница будет исчисляться порядками) и текст запроса в разы длиннее.

А мы всё заботимся о скорости работы и нагруженности сети за счет тонкого клиента и ... А тем ли заняты умы?

(0) в 8.3.20 всё будет
https://wonderland.v8.1c.ru/blog/novye-funktsii-yazyka-zaprosov-i-sistemy-komponovki-dannykh/

(80) Это уже не то.

(80) Ссылка была уже в посте (4).
Вопрос как умножить сейчас тоже решили уже вроде как ...

(80) а что там будет то? агрегатные функции не меняются

(83) Он про математические функции. В частности про варианты с ними в (25), с помощью которых можно произведение считать.

Аж голова заболела - всё равно, через (_|_) гланды вырезать

Подниму ветку.
А вот так еще не делали?
https://disk.yandex.ru/i/jSWfFY8YT6FaGA

Т.е. суть в получении строки вида "1.2*1.3*1.4" с помощью: Вычислить(СоединитьСтроки(Массив(КоэфСтрокой), "*", "*"))

(87) На СКД предложения выше были. Но не такое, а например (21) или через отдельное вычисление. Но изначально автора интересовал именно на языке SQL, через текст запроса.