JohnyDeath писал(а) 09. Июля 2010 :: 10:34:

1) С виду запрос построен правильно
2) Приведи структуру счетов которые укладываешь в список (описание субконто и из типов - может там все таки у субконто не Справочник.ДоговораСтрахования а просто Справочник)
3) Версию класса
3) Вот аналогичный текст запроса который у меня отработал правильно

    ТекстЗапроса = "
    |ВЫБРАТЬ
    | Обороты.ТекущийДокумент КАК [ДокДвижения $Документ]
    |,Обороты.ВидДокумента КАК [ДокДвижения_вид $ВидДокумента]
    |,Обороты.Счет КАК [Счет $Счет.Основной]
    |,Обороты.КорСчет КАК [КорСчет $Счет.Основной]
    |,Обороты.КоличествоОборотКт КАК КолВоКО
    |,Обороты.СуммаОборотКт КАК СуммаКО";
    ТекстЗапроса = ТекстЗапроса+"
    |ИЗ
    тов,БЕЗСУБКОНТО,(Сумма,Количество),";
    флУсловий = 0;
    Если GoodsList.РазмерСписка()>0 Тогда
	  ТекстЗапроса = ТекстЗапроса+"
	  |(Субконто1 В (ВЫБРАТЬ Val ИЗ #СзНоменклатуры))";
	  флУсловий = 1;
	  ПрямойЗапрос.УложитьСписокЗначений(GoodsList,"#СзНоменклатуры","Номенклатура");
    КонецЕсли;
    Если ПустоеЗначение(Склад)=0 Тогда
	  ТекстЗапроса = ТекстЗапроса+?(флУсловий=1," and ","")+"
	  |(Субконто2 = :ВыбСклад)
	  |";
    КонецЕсли;
    ТекстЗапроса = ТекстЗапроса+"
    |,) КАК Обороты ";
 

стрУсловие = " (Субконто2 = :Договор) "; 

Конечно же

Я так уже пробовал. Не катит.
Цитата:

(полное сообщение в прикрепленном файле)

Пробую указать в запросе и первое субконто:

ТекстЗапроса = "
	|ВЫБРАТЬ
	|	ОборотыОсновной.*
	|ИЗ $БИОбороты.Основной(:НачДата
	|	,:КонДата~
	|	,Документ
	|	,#Счета77
	|	,(Агенты_Брокеры, ДоговораСтрахования)
	|	,БЕЗКОРСЧЕТОВ
	|	,БЕЗСУБКОНТО
	|	,(Сумма)
	|	,"+стрУсловие+"
	|	,) КАК ОборотыОсновной
	|"; 

Так вываливает ошибку:
Цитата:

Еще вопрос. Хочу видеть табличку с колонками:
- Документ
- ДатаДокумента (ДатаОперации)
- Счет
- КоррСчет
- Сумма

По конкретному договору.
Если указываю периодичность "Документ", то Сумма группируется по текущему счету.
Например, у меня выписка делает две проводки по договору:
51 - 77.5.1 - 100 руб
77 - 77.5.1  - 10 руб. (Комиссия)
Хочу в итоговой таблице видеть обе эти строчки. А сейчас получаю сразу 110 по счету 77.5.1

Это вообще реально?

Так все таки получилось или нет?

Ну я думаю что имелось в виду что нельзя 1 счет указать параметром :ВыбСчет а именно требуется временной таблицей.

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

select
    case :ВидСубконто.<ИмяСубконто>
	  when ВидСубконто1 then Субконто1
	  when ВидСубконто2 then Субконто2
	  ....
	  when ВидСубконто<n> then Субконто<n>
    end as Субконто1
from ...
where :ВидСубконто.<ИмяСубконто> in (ВидСубконто1, ВидСубконто2,....ВидСубконто<n>) 

Т.е. мало того что чтобы получить значение субконто происходит проверка всех видов субконто по данной сроке, но и в условии на выборку накладывается условие отбора по виду.
При указании "Субконто2" данный запрос будет без секции условий и case в тексте выборки поля запроса.
Собственно на правильность это не влияло, но на оптимальность выполнения точно повлияло бы.
Далее. В самой первой версии с указанием имени параметра было использовано условие Субконто1. Тут ошибки нет. Действительно при указании вида субконто в условии он используются по тому номеру которому были в списке параметра субконто (корсубконто).
НО: условие в запросе к реальным таблицам 1С будет выглядеть как получение поля запроса (case) = ЗначениеСубконто. Согласитесь что это не самый оптимальный запрос. Поэтому можно было получить весьма неприятное время выполнения.
Достаточно было указать в параметре субконто - "Субконто2", и в условии "Субконто2 = :Договор". Таким образом выборка будет куда эффективнее.
Далее JohnyDeath не сказал формат БД. В DBF есть одна особенность использования сравнения. И данную особенность знают немногие. Она и была "исправлена" в новой версии. В общем суть в том, что SQLite сравнивает строки (!!!) с учетом правых пробелов и регистра символов. А поскольку поле "Субконто<n>" одно на таблицу итогов и движений, значение поле будет соответствовать максимальному значению вида субконто которое может быть под номером "n".
Т.е. если у вас есть два счета:
1. Счет А, Субконто1 - Справочник, Субконто2 - Строка.100, Субконто3 - Справочник.ВидСправочника
2. Счет Б, Субконто1 - Строка.100, Субконто2 - Справочник.ВидСправочника, Субконто3 - Справочник.ВидСправочника
Т.о. длина полей будет по максимальному значению: Субконто1 = 100, Субконто2 - 100Ю Субконто3 - 9 (справочник с указанием вида). И поэтому в DBF сравнение будет "недействительно". Поэтому Джонни и не получил желаемого результата.
Решается это следующим образом:

Субконто1 collate_1C = :ЗначениеСубконто 

Для SQL строка collate_1C будет проигнорировано, а для DBF проверка пройдет с учетом особенностей словаря 1С.
Так что имейте в виду.
Что касается дальнейших обсуждений, то там было по разному. leshik не знал что это DBF, думаю если бы знал то может быть сделал кое-какие предложения/предположения.
На будущее, для всех: обязательные условия для получения более точного ответа надо указать:
1. Оригинальный текст запроса
2. Текст запроса если РежимОтладки = 1
3. Версия класса (атрибут Версия)
4. Формат базы данных
Если вы используете 1.06.ххх рекламации рассматриваются только если переедете на 1.07. Если используете 1.07 то сначала попробуйте новую версию. Не помогает? welcome как говорится.

Ну и собственно по результатам обсуждения и моей попытке воспроизвести проблемы была найдена косвенная ошибка и исправлена.

Большое спасибо всем, кто принимал участие, в том числе и помогал ответить на вопросы до моего появления. Я действительно благодарен каждому активному пользователю.