Тема скорее пятничная.
Вот откапываете вы какой-то отчет, который писал человек, который давно уже свалил, вы его и в глаза не видели.
Вам (возможно частично) он кажется откровенно нубским.
Но есть вероятность, что отчет гениален, а это вы - нуб и этого не понимаете.
Вот как определить, кто именно в данном случае нуб? :)

(0) Все очень просто: текст кода покажи и я скажу кто из вас нуб.

(0) вокруг все дураки и не лечатся, один я тут стою в белом пальто весь красивый

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

(0) каждый программист нуб. И чем больше у него опыта и знаний тем больше он нуб

(0) обоснуй, что мой отчет нубский

+(3) 3в. Работает у него быстрее - ты нуб. У тебя быстрее - ты крутышка.

Не, ну ответ очевиден, нуб, тот, кто писал отчет до тебя, тут, как бы, и думать не очем :)).

(7)* не о чем. Фиг его знает как это пишется правильно.

(5) Ты намекаешь, что появилась интрига в ветке ?

Работает не трож ! или сделай лучше (быстрее, функциональнее)

(0) а зачем что-то определять?

вы точно не nOOb :)

(0)По диагонали слева на право прочитай код,если найдешь там слово "ты лошара" заначи ты нуб

(0) сомневаешься - сам нуб

(0) Чтобы у следующих программеров не возникало таких вопросов, вставляй камменты:

//
// Писал нуб. 24.02.ХХ с жуткого похмела
//

(0) покажи запрос то

(0) Работает - не трожь! Займись более полезным делом, поиграй в танчики :)

(0)Посмотрел твою фотку,поставил тебе плюсик

(15) Лучше так писать: // 8====================3

чтобы можно было приложить и сравнить

Нужен универсальный ответ.
А вообще как пример вот текст, который меня сильно смутил :).
   ТекстЗапроса="    
   |SELECT
   |    $Р.Клиент [Клиент $Справочник.Клиенты],    
   |    $Спр.ГоловнойКлиент [ГоловнойКлиент $Справочник.Клиенты]    
   |FROM
   |    $Регистр.Взаиморасчеты Р (nolock)
   |INNER JOIN
   |    _1sjourn Жур (nolock) ON Р.iddoc = Жур.iddoc    
   |    AND (Жур.Date_Time_IDDoc < :ДатаНачала)
   |    AND ($ФлагРегистра.Взаиморасчеты = 1)
   |    AND (Жур.IDDocDef = $ВидДокумента.РасходнаяКредит)
   |INNER JOIN $Справочник.Клиенты Спр (nolock) on Спр.ID = $Р.Клиент
   |Where Р.Debkred=1 "+ТекстУсловий+"
   |GROUP BY
   |    $Р.Клиент,
   |    $Спр.ГоловнойКлиент";

Если работает - не трогаю, пусть работает.
Если не работает - спрашиваю: а раньше работал? Что изменилось?
А вообще всякое бывает, бывают и у меня отчеты за которые потом стыдно. Все от нехватки времени и нечеткого ТЗ. Поэтому надо проще относиться.

(3) Задача такая: подправила справочник, перестал работать отчет.
Пару запросов курю уже полдня, наверное :).

(20) что типа в нем смутило?

(22) криворукая ты подправлялка

(0)>как определить, кто именно в данном случае нуб
- замер производительности и оценка объема его / своего кода (чем меньше - тем лучше)
- обсуждение с пользователями эргономичности и функциональности

(22) много не кури - кожа пожелтеет

(20) Я - нуб, никогда не писал запросов на 1С++
А что тут подозрительного?

Работает? Не трогай!

(20) А что смутило ?

(19) Показываешь, насколько отвисла твоя челюсть с двойным подбородком?

(23) Ты давай колись, в чем интрига ?

Когда смотрел код за одним крутым программером, он прямо в коде писал изредка, типа пишу г(о)внокод, потом переделаю когда время будет. Изредка видимо времени не оставалось. Щас сам так делаю, в каментах пишу
//г(о)внокод,
потом переделываю, обычно это выглядит так, второй раз заглядываю туда, встречаю свой камент, становится стыдно и переделываю. )

(20) Ну рассказывай, что смущает.

(23) Смутила вот эта строчка
AND (Жур.Date_Time_IDDoc < :ДатаНачала)
Учитывая, что запрос должен выполняться, если стоит галка "Только новые клиенты с ДатаНачала"
(4) Вот это похоже на правду, да :).
(15) Кстати, обычно так и делаю :).
(24) Да вот и стоит задача определить - у меня кривые руки или у того кто писал отчет :). Править реквизит справочника я как бы умею.

(34) Переделай все на православные семерочные запросы. Запрос писал нуб, раз не смог уже имеющимися средствами нужный функционал реализовать, и использовал костыли.

Код тормозит, причем адски.
Интрига в том, что данный отчет - всего лишь пример, вопрос "нуб ли я" возникает довольно часто. Надо найти критерий, которым пользуются все не-нубы :).
(32) Довольно часто так пишу, да :).

(34) Ну и, выбираются клиенты по которым были движения до ДатаНачала.
Дальше, наверное, этот список используется для проверки.
Или выводится в отчет сразу результат запроса ?

(34) всех устраивало ведь?

(35) Не, я согласна зваться нубом, но такое точно делать не буду :).

(36) Ну глянь на регистр, флаг Быстрая обработка движений стоит ?
Можно поставить, если нету, немного распухнет таблица движений, но можно будет выкинуть джойн с журналом.

(0) Обидеть художника может каждый, так же и докапаться к любому коду можно. Главный критерий это то пользуеются ли этим отчетом и есть ли к нему притензии от пользователей.

(40)+ И выкинь это
  |    AND ($ФлагРегистра.Взаиморасчеты = 1)
Оно там всеравно нафик не надо, из-за этого можешь в индекс не попасть.

(36) Ну естественно тормозит. Ты соединяешь кучу движений регистра с кучей записей из журнала документов. А надо-то тебе выбрать всего лишь клиентов... Уменьшай развер соединяемых таблиц.

(39) Ну, попробуй для начала переделать этот запрос. Получится быстрее и на встроенном языке 7.7 - значит, смело называй автора запроса нубом.

Я не понимаю, если мне надо с даты Х отобрать клиентов, зачем смотреть все движения по всем клиентам ДО даты Х...

(43) Нет, там выбираются клиенты по которым были движения до определенной даты.

(41) *так же = также;
*докапаться= докопаться;
*пользуеются =пользуется;
*притензии= претензии;

(44) Это уже вопрос к (38), отсюда не видно, что там дальше с ними делают.

(0) Нуб автор, ибо такие вопросы задает. Работает отчет, не трож. Не работает, перепиши.

(43) >>Уменьшай развер соединяемых таблиц
Не правильный совет
Правильно нужно в индекс попадать

Отчет работать перестал после того как в справочник была проставлен реквизит.
Проблема в том, что проставлять реквизит я как бы умею...

(45) Ну и? Зачем соединять таблицу всех движений, когда достаточно просто получить таблицу клиентов? Или что, у движений даты нет? Да даже просто группировка исходной таблицы до клиент и iddoc вполне может в разы сократить размер соединяемой таблицы.

(49) Уменьшение размеров таблиц дает эффект всегда, и, в общем-то, при правильной реализации не мешает получить бонус от попадания в индекс.

Остальной код выложить, или же тупо забиваем и решаем, что я всегда - нуб? :(

(0)Нуб тот кто писал этот отчет, потому что ты можешь сейчас это аргументировать начальству, а тот кто его писал, уже нет, да и ему уже пофиг на это.

(51) Ты не поверишь, но у движений в частном случае даты нет :).

(0) Не хочется тебя расстраивать, но...
Ответ на вопрос кто из вас нуб содержится в самом факте вопроса.

(52) Не комплексуй. Ты молодец! :)

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

(54) Ну тогда это меняет дело. Хотя почему бы в таком случае не выбрать клиентов из проведенных документов? Зачем тогда таблица регистра?

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

(58) Потому что признак проведения документа не дает гарантии что он сделал движения конкретно в этот регистр.

(60) Дык нафига тогда документ "РасходнаяКредит" с нулевой суммой? Или в какой еще ситуации такой документ не делает движений по взаиморасчетам? И, кстати, вопрос - а не должны ли попадать такие клиенты в отчет?

(51) Группировка по клиенту и iddoc в данном случае ничего не даст, полюс не забываем, что в скуле вы не задаете порядок обработки данных, вы только описываете, что вы хотите получить, а как там уже скуль построит план запроса, можно только примерно прикинуть.

(62) От конфигурации зависит. Если взаиморасчеты ведутся до позиции номенклатуры - еще как даст.

(63) Не, ну это уже фантастика :).
Я к тому, что может и так быть, но очень вряд ли.

(0) А какая разница КАК написан отчет ? Он либо работает (в смысле ПРАВИЛЬНО работает), либо - нет.

(64) Какая фантастика? Я такое реализовывал... потому что просто распределение по процентам начальство не устраивало - люди брали товар на реализацию и платили по мере реализации за вполне конкретный товар... считай, комиссионная торговля, только без отчетов комиссионеров.

(65) Ну он может работать быстро, либо медленно и печально.
В данном случае второе плюс есть ошибка, до которой никак не могу докопаться.

(0) У кого меньше кода и производительность лучше, тот крутой)

(67) В данном случае надо уточнить, зачем выбираются движения по регистру, а не документы. И правильно ли это.

И что за ошибка-то?

(67) Там еще вот это Р.Debkred=1 в условии убивает его сильно плюс неизвестно, что в ТекстУсловий.
Здесь опять же, насколько надо условие на направление движения Расход (кажется), зависит от требований к отчету.

(44) Например, чтобы исключить старых клиентов, по которым были движения до даты Х

(71) Непонятно как понять, стояла ли такая задача.
К тому же, допустим, в отчет надо вывести клиентов за такой-то месяц. Допустим, это 50 клиентов. Не логичнее ли проверить, присутствовали ли эти 50 клиентов в старых движениях, нежели получать все движения с момента работы базы. Или же я все-таки нуб? :(.

(72) Ну в том запросе в результат и выходят только клиенты, а не все движения.
Плюс для проверки, были ли в старых движениях эти 50 клиентов, все равно придется накладывать условия по дате на движения регистра, получится примерно та же песня, только вид сбоку.

(73) Да, но все старые 10 000 клиентов не будут выгружены в ТЗ и не будут забивать оперативу. Или же разницы нет?

(0) срочно замуж. Уже предлагали?

(74) С этой точки зрения, да, разница есть.

(75) Да. Детей тоже предлагали. :)
А почему, кстати?

(50) Ну судя по результату, всё-таки не умеешь добавлять реквизиты.

О детская невинность, о молодость... Надо было поднять тему, вместо того, чтобы сесть и прикинуть свои варианты реализации запроса. Делов то...

(78) Реквизит не добавлялся, а правился. Обработкой. Которую дал бывший программер :). Уже сто раз об этом пожалела.
Какой он был раньше - не помню. И имеет ли отношение данный реквизит к этой проблеме - тоже не знаю. Совпадение удивляет, но в селекте я в упор не вижу данного реквизита :).

Мне озвучили еще 2 варианта - "оба нубы" и "заниженная самооценка" :).

(80) Да давно бы уже выбрала штатным запросом из документов нужных клиентов...

(80) Случайно (38) не является тем самым бывшим программистом :), судя по его эмоциональной реакции ?
А то меня все мучает этот вопрос :).
Хочется скандалов, интриг, расследований.

(82) Хыыы. Размер базы озвучить или не стоит?
Скажем так, документы за день без правильных индексов выбираться будут ну ооочень долго :).

А мне интересно выяснить, почему все на мисте советуют замуж.
Уже не первая ветка, однако :).

(0) отчет работает? Ну и все чо. Не нравится - свой напиши.

Старые отчеты от предыдущих программеров та еще тема... Обычно приходится с нуля переписывать, чем переделывать этот гуанокод.

Кстати, в этом же отчете есть селекты, которые, по моему мнению, писали не нубы. Но выяснить, кто именно что писал - уже нет возможности...

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

(85) да так по приколу :)

(77) анекдот есть
Замуж, дура! Срочно замуж!

Молодая, симпатичная девушка приходит в церковь, подходит к священнику. При этом, на ней ни макияжа, ни бижутерии, ничего, даже одежда консервативно-строгая.

Потупив голову спрашивает: "Батюшка, а как вы понимаете концепцию протеирея Феофана о социально-патриархальном единении души человека с Господом Богом, на основании религиозных воззрений, высказанную для русской проваславной епархии в Париже"?

Батюшка: "Замуж, дура! СРОЧНО ЗАМУЖ!"

(84) Ну так в указанном запросе выбираются вообще все документы, и не за 1 день... Так что по-любому быстрее будет если в индекс не попадешь ;)

(87) Это типа один гуанокод заменять на другой :).
Это я не лично, а так в  общем.

(0) :)...а зачем? чсв качать? исправь то что считаешь неверным и считай себя 22см

(94) тогда уж "считай себя с 5-м размером")

(89) 5GB - это другая база. Тут много десятков гигабайт.
Реиндексацию уже сто лет как не делаем; новые реквизиты в справочник пихаем...

(94) Ну с ее полом как-то сложно с 22 см будет :).

(97) :) мальчишка.....у девочек аналог -22см

(96) А сколько этот запрос по времени выполняется, секунды, минуты, часы ?

(99) Минуты. Но у нас индексы правильные :).

(98) Мне больше нравится аналог как в (95) :)).

Мне не нравится 5 размер, мне и моего 3 много...

(101) :) вот видишь...а ТС нет

(100) Ну таки попробуй для эксперимента выкинуть из условия вот это

Р.Debkred=1

и из полей соединения вот это

|    AND ($ФлагРегистра.Взаиморасчеты = 1)

что получится по времени ?

про сиськи уже было?

(105) :) фотка ТС в ЛК, 3р.

(105) Почему было? Есть в личке у ТС немного, все как положено :).

(104) Сейчас пробую :).
Меня этот отчет уже задолбал; засунула запрос в отдельную обработку.

В отдельной обработке производительность запроса без этих 2х строчек не изменилась.
Однако там же он тормозит почему-то сильно меньше, чем в большом запросе.

(109) не надо их убирать, они могут как выпасть из индекса так и наоборот попасть в какую-то схему.

Текст запроса полностью с условием

(109) Когда SQL сервер одномоментно видит столько нубских ошибок, ему становится плохо, и он пока не придет в себя - тормозит :)

(109) Это в каком большом запросе, и как они связаны?
Похоже тут конкурс телепатов таки.

(110) если исходить из этого
"Смутила вот эта строчка
AND (Жур.Date_Time_IDDoc < :ДатаНачала)
Учитывая, что запрос должен выполняться, если стоит галка "Только новые клиенты с ДатаНачала" "

должен быть еще один запрос после выполнения этого

(110) Че то я этих полей ни в одном из индексов, что журнала, что таблицы движений не наблюдаю.
Ну оно в принципе уже не важно, раз не влияет на скорость.

Нет, нужна общая идея как отличить нуба от не-нуба.
Кстати, только что нашла у себя нубскую ошибку (правда исправила :)))
(113) Запрос есть, кидать?
P.S. сделала поиск по всему отчету по реквизиту, который правила - не вижу его вообще... в принципе...

(115) что за странные идеи, вообще? "нуб" - это понятие из компьютерных игр, означает новичок (пренебрежительно).
Работает - хорошо, медленно работает - оптимизируй запрос.
Кидай, чо уже там, нужно смотреть в комплексе

(116) :) это было давно и неправда...."независимо от того что и как вы делаете, нуб - это всякий кто делает это хуже, а задрот - кто лучше"

ТзОст = глСессия.ВыполнитьИнструкцию(ТекстЗапроса);
   
   //теперь выбираем справочник
   ТекстУсловий="";
   Если флГоловнойКлиент=1 Тогда        
       Если СписКлиентов.РазмерСписка()>0 Тогда
           ТекстУсловий=ТекстУсловий+"
           |    AND ($Спр.ГоловнойКлиент IN (SELECT Val FROM #СписКлиентов))";
           глСессия.УложитьСписокОбъектов(СписКлиентов, "#СписКлиентов", "Клиенты");
       КонецЕсли;        
   КонецЕсли;
   
   Если ВыбКлиент.Выбран()=1 Тогда
       Если ВыбКлиент.ЭтоГруппа()=1 Тогда
           ТекстУсловий=ТекстУсловий+"
           |    AND (Спр.ID IN (SELECT Val FROM #ВыбКлиент))";
           глСессия.УложитьСписокОбъектов(ВыбКлиент, "#ВыбКлиент", "Клиенты");
       Иначе
           ТекстУсловий=ТекстУсловий+"
           |    AND (Спр.ID =:ВыбКлиент)";
           глСессия.УстановитьТекстовыйПараметр("ВыбКлиент",ВыбКлиент);
       КонецЕсли;
   КонецЕсли;
   
   ТекстЗапроса="
   |SELECT
   |    Спр.ID [Клиент $Справочник.Клиенты],
   |    $Спр.ГоловнойКлиент [ГоловнойКлиент $Справочник.Клиенты],
   |   0 Уд
   |FROM
   |    $Справочник.Клиенты as Спр (nolock)
   |WHERE
   |    Спр.IsFolder = 2 AND
   |    Спр.IsMark = 0
   |"+ТекстУсловий+"
   |Order by
   |    $Спр.ГоловнойКлиент,Спр.ID";
           
   глСессия.РежимRPC(1);    
   глСессия.Отладка(Отладка);
   ТзСпр = глСессия.ВыполнитьИнструкцию(ТекстЗапроса);
   
   Если Отладка=1 Тогда
       глПросмотрТСЗ(ТзСпр, "Справочник клиентов");
       глПросмотрТСЗ(ТзОст, "Регистр взаиморасчетов");
   КонецЕсли;
   
   ПомеченоСтр=0;
   ТзСпрСтрок = ТзСпр.КоличествоСтрок();
   Для счЦ=1 По ТзСпрСтрок Цикл        
       ТзСпр.ПолучитьСтрокуПоНомеру(счЦ);
       ГоловнойКлиент = ТзСпр.ГоловнойКлиент;
       Если ПустоеЗначение(ГоловнойКлиент)=0 Тогда //клиент тогда не интересен
           Стр=0;
           Если ТзОст.НайтиЗначение(ГоловнойКлиент,Стр,"ГоловнойКлиент")=1 Тогда
               ТзСпр.Уд = 1; //значит продавал от кого-то
               ПомеченоСтр = ПомеченоСтр+1;
           КонецЕсли;
       Иначе
           Стр=0;
           Если ТзОст.НайтиЗначение(ТзСпр.Клиент,Стр,"Клиент")=1 Тогда
               ТзСпр.Уд = 1; //значит продавал
               ПомеченоСтр = ПомеченоСтр+1;
           КонецЕсли;
       КонецЕсли;
   КонецЦикла;
   
   сзНов=СоздатьОбъект("СписокЗначений");
   Если ПомеченоСтр>0 Тогда
       Если ПомеченоСтр = ТзСпр.КоличествоСтрок() Тогда
           ТзСпр.УдалитьСтроки();
       Иначе
           ТзСпр.Сортировать("Уд-");
           ТзСпр.Выгрузить(сзНов,ПомеченоСтр+1, ,"Клиент");
       КонецЕсли;
   Иначе
       ТзСпр.Выгрузить(сзНов, , ,"Клиент");
   КонецЕсли;
   
   Если Отладка=1 Тогда
       глПросмотрТСЗ(сзНов, "сзНов");
       глПросмотрТСЗ(ТзСпр, "Новые клиенты");
   КонецЕсли;
   
   Возврат сзНов;

Ну вот могу привести пример своей нубской ошибки (правда, исправленной, но на нее ушли пара часов :()

СпрКл = СоздатьОбъект("Справочник.Клиенты");
СпрКл.НайтиПоКоду("003041660049");
Сообщить(ТзОст.НайтиЗначение(СпрКл,"","Клиент"));

:)...это не пример нубской ошибки...это пример нубского кода

(119) Код по определению нубский, т.к. это была отладка :).
Но вот этот самый нубский код содержал ошибку, на которую ушли пара часов...

(34) Везде один и тот же комментарий?
//
// Писал нуб с жуткого бодуна
//

(122) Неа :(. Такой коммент ставлю я, когда реально пишу с бодуна :).
Насторожил тот факт, что при установке галки отчет начинал реально тормозить и вешать систему...

(123) Ты бываешь с жуткого бодуна?
Млин! А я чуть было не влюбился. (

(123) Вот этой
Если флГоловнойКлиент=1 Тогда  

что ли ?

И где тут то запрос, который раньше обсцждали ?

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

(125) После запроса что раньше обсуждали идет вышеприведенный код.
(126) О да, буквально вчера такое было :).

(124) Ну такие как вы, которые чуть не влюбились, спаиваете :)

(127) с каким флагом "тормозит"?

(118)      //теперь выбираем справочник
  ТекстУсловий="";
  Если флГоловнойКлиент=1 Тогда        
      Если СписКлиентов.РазмерСписка()>0 Тогда
          ТекстУсловий=ТекстУсловий+"
          |    AND ($Спр.ГоловнойКлиент IN (SELECT Val FROM #СписКлиентов))";
          глСессия.УложитьСписокОбъектов(СписКлиентов, "#СписКлиентов", "Клиенты");
      КонецЕсли;        
  КонецЕсли;
   
  Если ВыбКлиент.Выбран()=1 Тогда
      Если ВыбКлиент.ЭтоГруппа()=1 Тогда
          ТекстУсловий=ТекстУсловий+"
          |    AND (Спр.ID IN (SELECT Val FROM #ВыбКлиент))";
          глСессия.УложитьСписокОбъектов(ВыбКлиент, "#ВыбКлиент", "Клиенты");
      Иначе
          ТекстУсловий=ТекстУсловий+"
          |    AND (Спр.ID =:ВыбКлиент)";
          глСессия.УстановитьТекстовыйПараметр("ВыбКлиент",ВыбКлиент);
      КонецЕсли;
  КонецЕсли;
   
  ТекстЗапроса="
  |SELECT
  |    Спр.ID [Клиент $Справочник.Клиенты],
  |    $Спр.ГоловнойКлиент [ГоловнойКлиент $Справочник.Клиенты],
  |   0 Уд
  |FROM
  |    $Справочник.Клиенты as Спр (nolock)
  |WHERE
  |    Спр.IsFolder = 2 AND
  |    Спр.IsMark = 0
  |    AND Спр.ID NOT IN (SELECT Val FORM #СписокСтарыхКлиентов)
  |    AND $Спр.ГоловнойКлиент NOT IN (SELECT Val FORM #СписокСтарыхГоловных)
  |"+ТекстУсловий+"
  |Order by
  |    $Спр.ГоловнойКлиент,Спр.ID";
           
  глСессия.РежимRPC(1);    
  глСессия.Отладка(Отладка);
 
  СписокСтарыхКлиентов = СоздатьОбъект("СписокЗначений");
  СписокСтарыхГоловных = СоздатьОбъект("СписокЗначений");
 
  ТзОст.Выгрузить(СписокСтарыхКлиентов,,,"Клиент");
     
  ТЗВрем = СоздатьОбъект("ТаблицаЗначений");
  ТзОст.Выгрузить(ТЗВрем);
  ТЗВрем.Свернуть("ГоловнойКлиент",);
  ТЗВрем.Выгрузить(СписокСтарыхГоловных);
  СписокСтарыхГоловных.УдалитьЗначение(СписокСтарыхГоловных.НайтиЗначение(ПолучитьПустоеЗначение("Справочник.Клиенты")));// удалим пустое если было
 
  глСессия.УложитьСписокОбъектов(СписокСтарыхКлиентов, "#СписокСтарыхКлиентов");  
  глСессия.УложитьСписокОбъектов(СписокСтарыхГоловных, "#СписокСтарыхГоловных");  
 
  ТзСпр = глСессия.ВыполнитьИнструкцию(ТекстЗапроса);
 
  сзНов = СоздатьОбъект("СписокЗначений");
  ТзСпр.Выгрузить(сзНов, , ,"Клиент")
 
  Если Отладка=1 Тогда
      глПросмотрТСЗ(ТзСпр, "Справочник клиентов");
      //глПросмотрТСЗ(ТзОст, "Регистр взаиморасчетов");
  КонецЕсли;

  Возврат сзНов;

(129) При установке данного флага выполняются все запросы, приведенные выше. Функция возвращает сзНов и пихает его в основной селект. Как-то так.
Без него эта функция вообще не выполняется и тормозов нет.

(131) и в чем тормоза? долго отчет формируется?
Регистр распух значит уже..
Думаю можно добавить для клиентов новый реквизит - Дата создания и опираться уже на него

(132)
1) Реквизит уже есть. Собственно он и правился. Сейчас выясняю, почему клиенты в отчет не попадают.
2) В справочник Клиенты нельзя добавить новый реквизит. Объем базы слишком велик.
И вообще, тема была не об этом. :(

(133) ну, если тема в "нубстве" только..
Все были нубами когда-то, не все ли равно?) каждый пишет как позволяют ему его способности и знания.
Если отчет кажется "нубским" - пусть так и будет, и не парься, Можно переписать под себя - тебе же с этим работать.

(133) Поэкспериментировал немного, интересно стало.
Замени inner на Left тут

  |FROM
   |    $Регистр.Взаиморасчеты Р (nolock)
   |INNER JOIN
   |    _1sjourn Жур (nolock) ON Р.iddoc = Жур.iddoc    

там где справочник джойнится оставь inner. Должно полегчать.
Ну и что-то типа (130), чтоб не насиловать ТЗ.

Я пока что пришла к выводу, что мы оба нубы :(.

Предварительный вердикт такой:
1) Код нубский;
2) Пока я его не переписала на работающий не-нубский я тоже нубас :).
И кстати, пока прихожу к выводу, что правка справочника тут все-таки не причем...