Все началось с того, что один мой знакомый припер приладу для 1С, позволяющую из нее обращаться через "OLEDBData" к библиотекам VisualFoxPro. Использование этого средства позволяет ускорить выполнение запросов в 5 раз по сравнению со стандартными 1С-овскими запросами. Одна беда. Работает все это на языке SQL-запросов, который для нас, 1С-ников, таинственнен и неведом.
В итоге, мне удалось реализовать SQL-запрос, но кое-что гложет душу. Никак не получается использовать в условии список значений :((. Скажем так. В языке запросов 1С допускается такая конструкция: Условие (КодОперации В СписокКодовОпераций), где СписокКодовОпераций - это список значений, примерно 6 символьных переменных, коих в принципе может быть любое количество. Я репу почесал, и поставил в условии вместо знака = предлог IN. Получилось следующее: $РегПрихРасхПДТ.КодОперации IN :КодыОперацийПродажи.* Так вот этот... нехороший Parser обложил мое творение матом: Sintax error. А как бы хотелось использовать в условиях список значений!

*Здесь $РегПрихРасхПДТ.КодОперации - это макроподстановка, которая при выполнении запроса преобразуется, например, в RA1596.7484 (таблица и ее поле). Не знаю как, но как-то он это делает.

Щас, попробую.

Слушай, PaulWist, а нельзя ли вместо (select связанное_ключевое_поле from MyTable2) использовать какой-нибудь array, например? У меня коды то не в таблице. :(

Короче, текст запроса выглядит так:

SELECT
VT.Покупатель as [Покупатель $Справочник.Контрагенты],
VT.Товар as [Товар $Справочник.Номенклатура],
VT.ТекДок as [ТекДок $Документ],
MAX(VT.КодОперации) as КодОперации,
Sum(VT.Стоимость) as СуммаСебПродаж,
Sum(VT.СумПродаж) as СуммаПроПродаж,
Sum(VT.НДСрасхода) as СуммаНДСРасход,
Sum(VT.КолВоКГ) as КоличествоКГ,
Sum(VT.СтоимостьВ) as СуммаСебПродажВ,
Sum(VT.СумПродажВ) as СуммаПроПродажВ,
Sum(VT.НДСрасходаВ) as СуммаНДСРасходВ,
Sum(VT.КолВоКГВ) as КоличествоКГВ
FROM ( SELECT
$РегПрихРасхПТ.Контрагент as Покупатель,
$РегПрихРасхПТ.Товар as Товар,
РегПрихРасхПТ.IDDoc as ТекДок,
$РегПрихРасхПТ.КодОперации as КодОперации,
(1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.Стоимость as СтоимостьВ,
РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.Стоимость as Стоимость,
(1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.Оборот as СумПродажВ,
РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.Оборот as СумПродаж,
(1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.НДСрасхода as НДСрасходаВ,
РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.НДСрасхода as НДСрасхода,
(1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.ОстатокВКг as КолВоКГВ,
РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.ОстатокВКг as КолВоКГ
FROM
$Регистр.ПартииТоваров as РегПрихРасхПТ
INNER
JOIN 1SJourn as J ON РегПрихРасхПТ.IDDOC=J.IDDOC
WHERE
(J.DATE >= :ВыбНачПериода~~) AND (J.DATE <= :ВыбКонПериода~~) AND (J.$ФлагРегистра.ПартииТоваров=1) AND
$РегПрихРасхПТ.Фирма = :ВыбФирма AND
$РегПрихРасхПТ.КодОперации IN :КодыОперацийПродажи
) as VT


GROUP BY
Покупатель,
Товар,
ТекДок
HAVING
Sum(СтоимостьВ) <> 0 or
Sum(Стоимость) <> 0 or
Sum(СумПродажВ) <> 0 or
Sum(СумПродаж) <> 0 or
Sum(НДСрасходаВ) <> 0 or
Sum(НДСрасхода) <> 0 or
Sum(КолВоКГВ) <> 0 or
Sum(КолВоКГ) <> 0

А КодыОперацийПродажи - это список символьный значений - читай: одномерный массив.

Все, разобрался. Спасибо всем сочуствующим. :)

$РегПрихРасхПТ.КодОперации IN :КодыОперацийПродажи
заменил на
$РегПрихРасхПТ.КодОперации IN (:КодыПродажи1,:КодыПродажи2)
причем это наращивается в цикле с помощью созданной мной процедуры. Т.е. будет в списке 40 значений, будет IN (:КодыПродажи1,:КодыПродажи2) длиной 40 значений.
Но это работает.

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

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

На форуме 1С это бесполезно спрашивать. Здесь SQL-то фоксовый!

Народ, хотите узнать, как на языке 1С выглядит тот же самый запрос, который я здесь привел?

ПЕРИОД С ВыбНачПериода По ВыбКонПериода;
Фирма = Регистр.ПартииТоваров.Фирма;
Товар = Регистр.ПартииТоваров.Товар;
Покупатель = Регистр.ПартииТоваров.Контрагент;
СумПродаж = Регистр.ПартииТоваров.Оборот;
НДСрасхода = Регистр.ПартииТоваров.НДСрасхода;
КолВоКГ = Регистр.ПартииТоваров.ОстатокВКг;
Стоимость = Регистр.ПартииТоваров.Стоимость;
КодОперации = Регистр.ПартииТоваров.КодОперации;
ТекДок = Регистр.ПартииТоваров.ТекущийДокумент;
Функция СуммаСебПродаж = Расход(Стоимость);
Функция СуммаПроПродаж = Расход(СумПродаж);
Функция СуммаНДСРасход = Расход(НДСрасхода);
Функция КоличествоКГ = Расход(КолВоКГ);
Функция СуммаСебПродажВ = Приход(Стоимость);
Функция СуммаПроПродажВ = Приход(СумПродаж);
Функция СуммаНДСРасходВ = Приход(НДСрасхода);
Функция КоличествоКГВ = Приход(КолВоКГ);
Группировка Покупатель без групп;
Группировка Товар без групп;
Условие (Фирма=ВыбФирма);
Условие (Не(КолВоКГ=0));
Условие (КодОперации В КодыОперацийПродажи);

Результирующая таблица получается та же самая! )

Да ладно тебе, Pahan! Это же FoxPro-шный форум. Навряд ли им интересны наши 1С-овские заморочки. Мне нужна была подсказка по языку SQL-запросов FoxPro, я ее получил. А то, что там Parser построен на обращении к библиотекам VisualFoxPro через посредника СРР, являющегося еще одной не родной 1С-овской компонентой, которая и преобразует для них $бла-бла-бла в ИмяТаблицы.ИмяКолонки на основе данных из 1cv7.dd, навряд ли их заинтересует. Как и то, что СписокЗначений является не простым массивом, а многомерным, со сложной внутренней структурой. Главное, что это массив!

В свое время я тоже любовался результатом его выгрузки в строку: 9 колонок, из которых 8 - служебные. Но это все равно массив! И ведет себя, как типичный массив. Если ты скажешь, что он умеет сортироваться, то я отвечу, и народ меня поддержит, что в том же FoxPro есть функция ASORT(), позволяющая прекрасно сортировать любые виды массивов. И вообще, если брать FoxPro, то там имеется довольно богатый набор функций, начинающихся на "A". Меньше, чем для работы с реальными dbf-таблицами, но все же достаточно внушительный. И, уверяю тебя, этот СписокЗначений на фоксине опытному программеру можно реализовать на раз.

Проходящий прав. SQL-вариант действительно дает дополнительную надежность и возможность работы с намного большим количеством пользователей, чем DBF. Но вот в скорости выигрыша никакого. Более того, из практического опыта могу сказать, что при подключении одного пользователя в SQL-варианте и в DBF-варианте первый проигрывает в скорости примерно в 1,5-1,7 раза. Это я сужу с чужих слов, но цифра примерно такая. Просто народ тренировался делать свертку базы в DBF-варианте, а производил в SQL, и имел возможность сравнить.

Вы лучше скажите, что я в этот раз накосячил. Вот текст запроса:

|SELECT
| VT.Покупатель as [Покупатель $Справочник.Контрагенты],
| VT.Товар as [Товар $Справочник.Номенклатура],
| VT.ТекДок as [ТекДок $Документ],
| VT.КодОперации as КодОперации,
| VT.ВидРегистра as ВидРегистра,
| Sum(VT.Стоимость) as СуммаСебПродаж,
| Sum(VT.СумПродаж) as СуммаПроПродаж,
| Sum(VT.НДСрасхода) as СуммаНДСРасход,
| Sum(VT.КолВоКГ) as КоличествоКГ,
| Sum(VT.СтоимостьВ) as СуммаСебПродажВ,
| Sum(VT.СумПродажВ) as СуммаПроПродажВ,
| Sum(VT.НДСрасходаВ) as СуммаНДСРасходВ,
| Sum(VT.КолВоКГВ) as КоличествоКГВ
|FROM ( SELECT
| $РегПрихРасхПТ.Контрагент as Покупатель,
| $РегПрихРасхПТ.Товар as Товар,
| РегПрихРасхПТ.IDDoc as ТекДок,
| $РегПрихРасхПТ.КодОперации as КодОперации,
| 'ПТ' as ВидРегистра,
| (1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.Стоимость as СтоимостьВ,
| РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.Стоимость as Стоимость,
| (1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.Оборот as СумПродажВ,
| РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.Оборот as СумПродаж,
| (1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.НДСрасхода as НДСрасходаВ,
| РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.НДСрасхода as НДСрасхода,
| (1-РегПрихРасхПТ.DEBKRED)*$РегПрихРасхПТ.ОстатокВКг as КолВоКГВ,
| РегПрихРасхПТ.DEBKRED*$РегПрихРасхПТ.ОстатокВКг as КолВоКГ
| FROM
| $Регистр.ПартииТоваров as РегПрихРасхПТ
| INNER
| JOIN 1SJourn as J ON РегПрихРасхПТ.IDDOC=J.IDDOC
| WHERE
| (J.DATE >= :ВыбНачПериода~~) AND (J.DATE <= :ВыбКонПериода~~) AND (J.$ФлагРегистра.ПартииТоваров=1) AND
| $РегПрихРасхПТ.Фирма = :ВыбФирма AND
| $РегПрихРасхПТ.КодОперации IN ('П','Ж','Т')
| UNION ALL
| SELECT
| $РегПрихРасхПДТ.Контрагент as Покупатель,
| $РегПрихРасхПДТ.Товар as Товар,
| РегПрихРасхПДТ.IDDoc as ТекДок,
| $РегПрихРасхПДТ.КодОперации as КодОперации,
| 'ПДТ' as ВидРегистра,
| (1-РегПрихРасхПДТ.DEBKRED)*$РегПрихРасхПДТ.Стоимость as СтоимостьВ,
| РегПрихРасхПДТ.DEBKRED*$РегПрихРасхПДТ.Стоимость as Стоимость,
| (1-РегПрихРасхПДТ.DEBKRED)*$РегПрихРасхПДТ.Оборот as СумПродажВ,
| РегПрихРасхПДТ.DEBKRED*$РегПрихРасхПДТ.Оборот as СумПродаж,
| (1-РегПрихРасхПДТ.DEBKRED)*$РегПрихРасхПДТ.НДСрасхода as НДСрасходаВ,
| РегПрихРасхПДТ.DEBKRED*$РегПрихРасхПДТ.НДСрасхода as НДСрасхода,
| (1-РегПрихРасхПДТ.DEBKRED)*$РегПрихРасхПДТ.ОстатокВКг as КолВоКГВ,
| РегПрихРасхПДТ.DEBKRED*$РегПрихРасхПДТ.ОстатокВКг as КолВоКГ
| FROM
| $Регистр.ПартииДоставкаТоваров as РегПрихРасхПДТ
| INNER
| JOIN 1SJourn as J ON РегПрихРасхПДТ.IDDOC=J.IDDOC
| WHERE
| (J.DATE >= :ВыбНачПериода~~) AND (J.DATE <= :ВыбКонПериода~~) AND (J.$ФлагРегистра.ПартииДоставкаТоваров=1) AND
| $РегПрихРасхПДТ.Фирма = :ВыбФирма AND
| $РегПрихРасхПДТ.КодОперации IN ('П','Ж','Т')
|) as VT
|
|
|GROUP BY
| Покупатель,
| Товар,
| ТекДок,
| КодОперации,
| ВидРегистра
|HAVING
| Sum(КолВоКГВ) <> 0 or
| Sum(КолВоКГ) <> 0

Что происходит. Если записи со сходными идентификаторами (Покупатель, Товар, ТекДок, КодОперации) присутствуют в обеих таблицах, то они прекрасно суммируются, а вот если только в первой, то просто напросто в выборку не попадают.
Группировка ВидРегистра - это просто метка, но она нужна. В первой таблице в колонке Покупатель находятся поставщики (такова структура БД), и их в отчете надо будет отловить и перезаполнить на покупателей.

Есть какие-нибудь мысли на этот счет? В принципе, если вы это подскажете, то я от вас наконец-то отлипну. :)

Ну все, пошло го@но по трубам! Работает.

В общем, AlexiS, по твоей методике докопался до истины. Оказалось - особенность Parser'а: Для подачи документов в результирующую таблицу РегПрихРасхПДТ.IDDoc as ТекДок недостаточно, надо еще вторую колонку J.IDDocDef as ТекДок_вид.

Aptex, компонента бесплатная, но, где он ее нарыл - не знаю. Узнаю - скажу.