Ковыряю БП 2.0 и наткнулся на такой код

ТекстЗапроса =
  "ВЫБРАТЬ
  |    Док.Дата КАК Дата
  |ИЗ
  |    Документ.АвансовыйОтчет КАК Док
  |ГДЕ
  |    Док.Ссылка = &Ссылка";
  Запрос.Текст = СтрЗаменить(ТекстЗапроса, "Документ.АвансовыйОтчет", "Документ." + Источник.Метаданные().Имя); (с) Общий модуль->ОбщегоНазначения-> ПередЗаписьюДокументаДляУдаленияДвиженийПередЗаписью

Почему сразу нельзя написать
ТекстЗапроса =
  "ВЫБРАТЬ
  |    Док.Дата КАК Дата
  |ИЗ Документ." + Источник.Метаданные().Имя+" КАК Док
  |ГДЕ
  |    Док.Ссылка = &Ссылка";


Это что код студента или действительно так методологически правильно?

а вдруг он проверял запрос конструктором?))))))

Причем тоже не понятно, почему нельзя просто написать

Запрос.Текст = СтрЗаменить(ТекстЗапроса, "АвансовыйОтчет", "" + Источник.Метаданные().Имя);

Типа для надежности?

"АвансовыйОтчет" - это первый док в метаданных.
Стыковать запрос из строк - теперь эта практика считается плохой (и это правильно !)

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

(3) Не понял. Типа

ТекстЗапроса="Начало "+" Конец"; - это не по пацански?

Настоящие пацаны пишут
ТекстЗапроса="Начало Бред Конец";

Запрос.Текст = СтрЗаменить(ТекстЗапроса, "Бред ", "Середина");
?
А в чем крутость такого кода? Вряд ли он будет от этого работать быстрее. Типа читабельность выше?

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

Было бы логичней, если б вместо "Документ.АвансовыйОтчет" писали что-то типа "ДокументыВыборки" или типо того, а то этот авансовый отчет смущает

(7) Ёе мае... это же опять же для конструктора. ДокументыВыборки он них не поймет

(0) Такую методологию во всю пропагандируют приближённые к 1С. Скоро сама 1С в стандарт это запишет. Есть несколько статей на инфостарте.

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

(10) >>...Я всегда думал что настоящий 1С-ник должен писать код без конструктора...

В течении дня написать несколько запросов по паре страниц и твоя должность 1С-ник-машинистка :)

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

по поводу почему СтрЗаменить(ТекстЗапроса, "Документ.АвансовыйОтчет", "Документ." + Источник.Метаданные().Имя); а не Запрос.Текст = СтрЗаменить(ТекстЗапроса, "АвансовыйОтчет", "" + Источник.Метаданные().Имя);

+(12) блин... все время путаюсь с ентер и контрол+ентер...
первый вариант может быть проще адаптирован к другим типам метаданных и он не зацепит случайной заменой ничего другого, что имеет подстроку "АвансовыйОтчет"

Все одинесники деляться на 2 типа - те, которые защищают косячный код разработчиков и те, кто его осуждают:)

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

(15) а я наоборот - только недавно ворвался в конструктор :)
удобно алиасы таблиц переименовывать :)

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

Хотя конечно запрос из трех строк мне проще ручками сделать, чем конструктор вызывать.

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

(18) о, точно... но я чаще не для проверки, а для форматирования текста запроса открываю :)

+19 ибо всякие юнионы проще руками налепить бывает, нежели в конструкторе поля выбирать или в том же конструкторе редактировать текст

(0) Унификация и стандартизация - есть "гуд"... даже если она выглядит, по вашему мнению,... эээ... несколько абсурдно :)

Просто разработчиков заставляют пользоваться возможностями платформы по максимуму:)
- Зачем мы создавали конструктор запросов, если ты запрос набиваешь руками?? - пеняет руководитель молодого прыщавого программиста. - Делай все запросы через конструктор!!

если вам нравится печатать - идите в машинистки. запрос конструктором "пишется" быстрее в разы!

(23) да ладно... :) не всегда, а особенно когда видишь конструктор первый раз

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

а самое главное, когда ты единственный владелец кода, можешь писать свой гамнокод руками хоть до опупения - тебе одному в нем и разбираться потом. Но когда разработчиков >1, уже приходится думать, _как_ написать, чтобы потом не пришлось объяснять 50 раз _что_ ты написал

+(25) и изменения вносить проще, чем ползать по конструктору

(25) если текст запроса >1 экрана, то он не может быть весь перед глазами. в конструкторе он разбит на логические блоки

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

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

(30) но в (0)-то запрос в несколько строк.  Делая так, как предлагает автор мы только упростили бы код

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

(31) унификация. это тоже к (26)

(33)+ сегодня в нем 5 строк, завтра - 25. что - не бывает такого?

(30) забыл уточнить:) имел ввиду мелкие изменения: добавить поле, условие, синоним назначить
(32) раскорячка начинается, когда большой запрос открывается в конструкторе и начинаешь ходить с закладки на закладку

(35) а прsufnm на 3-4 экрана туда-сюда - это нормально?

прsufnm  = прыгать

(0) Сам так часто делаю. Это для того чтобы запрос можно было в конструкторе открыть.

(28),(36) в моем представлении логический блок - это не список выбираемых полей или условий, а по крайней мере одна временная таблица. такое вполне помещается на 1 экран.

(0) нормальный способ... а главное - удобный...

>> Запрос.Текст = СтрЗаменить(ТекстЗапроса, "Документ.АвансовыйОтчет"
это охрененно читабельно...

Поддерживаю Asmody.

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

Согласен, что прогер... эээ... местами творческая профессия :)

Но здесь - чистое ремесло и никакой отсебятины :(

По мне - так проще написать стандартизованную конструктором болванку-шаблон, который потом несколькими строками кода видоизменить так, как мне надо.

Указанный код - легко модифицирующийся. В этом его несомненный "плюс".

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

уж лучшеб тогда придумали что нибудь типа Запрос.УстановитьПараметр
чем такую херню с Авансовым отчетом городить..

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

Я "ЗА" конструктор запросов. Могу им собрать практически любой запрос, нарисовать вручную пакет хотя бы из 3 запросов, каждый состоящий из объединений по 3-4 запроса и ни в чем не ошибиться - нафик, а конструктором собирается минут за 10, причем этот текст запроса без лишнего гемора отлаживается либо консолями запроса либо консолями отчета.
ЗЫ Помнится моя мама тысячу лет назад заикнулась "Настоящие проггеры должны программировать без мышки", на что я открыл ей винду и офис и сказал "настоящие юзеры не должны юзать мышку, пользуйся хоткеями...Любопытно как ты рисовать будешь...."

(45) одно дело сделать минимальными усилиями только то, что требуется, другое писать код так, что при доработке его проще выкинуть и начать заново...

Я код вроде (0) задолго (уж года 3 точно) до 1С писать начал и до сих пор плююсь видя склеенные из кусков запросы.

(45) другой умный человек сказал: "keep it simple stupid"

(0) Вот еще пример. Как думаешь в чем смысл условия:

Запрос=Новый Запрос;
Запрос.Текст="ВЫБРАТЬ
|    Заявка.Ссылка
|ИЗ
|    Документ.Заявка КАК Заявка
|ГДЕ
|    Заявка.Комментарий = ""тест""";

Результат=Запрос.Выполнить();

Выборка=Результат.Выбрать();
Пока Выборка.Следующий() Цикл
    ДокументОбъект=Выборка.Ссылка.ПолучитьОбъект();
   
    Если Ложь Тогда
       ДокументОбъект=Документы.Заявка.СоздатьДокумент();
   КонецЕсли;
   
   ДокументОбъект.Водитель=Водитель;
   ДокументОбъект.Комментарий="ааа";
    ...

(50) Это все потому что в 8 телепат кривой ((

Ага :) Ты тоже так пишешь!

(49) для меня проще 2-й вариант

(51) не подсказывай...

(53) Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете. (с) Кто-то

(55) Макконнелу приписывают, хотя на самом деле он сам откудо то скопипастил

Я бы сказал "... так, чтобы не было стыдно за написанное" :)

Сколько раз уже так бывало: просишь автора темы озвучить полный код, а он... молчит и уходит от ответа :(

(57) автор обиделся... он рассчитывал на поддержку, но 1С-ники опять оказались тупыми...

(50) ну дык в чём великий смысл?

(59) в том, что 1С-ники - жутко ленивый народ...

Очередной спор тупоконечников с остроконечниками

(60) ну блин, я не могу проверить, у меня висит всё.

(62) это была подсказка )))

(63) аа, это типа как то так должно быть?

Если НЕ Выборка.Ссылка.ПолучитьОбъект() Тогда    
 ДокументОбъект=Документы.Заявка.СоздатьДокумент();
КонецЕсли;

(+64) ну тоесть совсем не так, но смысл ясен..

(64) ДокументОбъект<Ставим точку и выбираем нужный реквизит из списка а не пишем его имя руками>

(64) нет

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

Если запрос на пару листов, то понять его смысл тяжело.

по поводу доработки - ни кто не мешает поставить точку остановки и посмотреть уже собраный текст.

(58) Нет я искал ответ и получил его.

(68) согласен.
А вообще комментарии к коду решают многие вопросы читаемости кода.

(64) Нет смысл в том, что телепат через точку не будет работать, потому что он не знает кто такой ДокументОбъект, поэтому мы явно ему говорим, что ДокументОбъект - это документ Заявка.

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

А я вот, когда в ЗУПе увидел строчку

Сообщить("Отчет не поддерживает вывод расчетной ведомомсти в разрезе группировко.");

грешным делом подумал, что 1С в кодеры набрали либо бландинко, либо жителей падонкоффстана… И то, и то, пожалуй, есть признак начала заката великой империи…    :0)

(72) В типовой 7-ке комплексной в каком то из древних релизов было такое сообщение "поле не заполенено"

(71) хренасе..

(73) Поле заполенивали-заполенивали, да не заполенили…

(71) Автор остался при своём мнении :) Можно конечно код отладочный убирать... А по мне - так лучше в комменты его. Пригодится ещё при последующей модификации/отладки.

(70) писать подробные комментарии к непонятному коду, это как скрывать запах гуана с помощью флакона духов...

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

интересно, те кто пишет что запрос пишется без использования конструктора писали/смотрели/отлаживали запросы например в УПП, где запрос может занимать 3-4 страницы? или такие как в (0) только запросы пишем?

(77) Запах духов не помешает в данном случае :)

(80) ИМХО лучше все же от причины запаха избавится...

(79) Не поверишь, но многие на 7-ке пишут без телепата, и ничего, живут как то. Даже пишут что-то.

К чему этот бессмысленный холивар конструктор VS руки? Почему обязательно навязывать свое мнение? Кому то удобно конструктором, кто то пишет конструктором и допиливает руками, а кто-то всю жизнь SQL запросы писал и он даже не знает, где конструктор расположен.

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

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

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

А писать нужно так, что-бы не лазить в запрос раз в неделю...

ИХМО - запросы в 10 листов текста - это бред. Если уж надо то делается большой, то делаем несколько запросов с одной временной таблицей, при таком подходе в промежутке между запросами можно подоптимизировать текст следующего запроса, или вообще от него отказатся...

(85)+1

(85) я в контексте создания текста запроса с врезками кода, даже написанный заранее запрос не так просто модифицировать врезками и убедится, что код работоспособен

(45) "...один умный человек сказал, что не надо делать то что сейчас не нужно, но потом может пригодиться..."
И в чем он умный? Если знаешь, что могут обокрасть, то ставишь замок на дверь. Согласно Вашему утверждению, это лишнее. Те кто делают что-то с взглядом вперёд, просто имеют больше опыта и умеют просчитывать на один-два хода дальше. Все начинающие шахматисты видят только на ход вперёд, а бывалые на несколько. Разве вторые более бестолковые?
К этому подходят такие поговорки:
"Уважай других, что бы уважали тебя"
"Сложно и не нужно - разные вещи"

Кстати, в начале своей карьеры я тоже гордился, что в моём коде ни кто не может разобраться, теперь я этого стыжусь

(85) Ну отладил ты свой запрос в консоле а дальше то что? Надо же как то вкраплять свои куски в эту солянку

(85) Декомпозиция объектов - сложная тема и для многих очень сложная и не понятная. Как Вы определяете, что запрос большой? "На глаз" или по какой-то методике? Если первое, тогда найдется тот, кто сможет опровергнуть Ваше утверждение

а голосовалку еще не поздно прикрутить? =)

(91) а смысл?

Имхо, код в (0) - чушь. Унификация должна делать код читабельнее, а не наоборот

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

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

+(88)(95) если мне не нравится мой код, написанный раннее, то я рад, что научился писать еще лучше и двигаюсь вверх, а не остановился в развитии... но код при необходимости приходится переписывать =(

(88) >> Если знаешь, что могут обокрасть, то ставишь замок на дверь.
В этом примере замок на двери уже нужен, т.к. он выполняет роль защиты. Поэтому он не лишнее.

(0) А так еще универсальнее:
ТекстЗапроса =
"ВЫБРАТЬ
|    Док.Дата
|ИЗ
|    &ИсточникДокумент КАК Док
|ГДЕ
|    Док.Ссылка = &Ссылка";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&НужныйДокумент", "Документ." + Источник.Метаданные().Имя);

(98) Не взлетит. ИсточникДокумент <> НужныйДокумент
Но такой код по крайне мере более читабельный, так как заранее предполагает замену

опа

Америка Европа

(99) блин, точно. косяк
вот так правильно:
ТекстЗапроса =
"ВЫБРАТЬ
|    Док.Дата
|ИЗ
|    &ИсточникДокумент КАК Док
|ГДЕ
|    Док.Ссылка = &Ссылка";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ИсточникДокумент", "Документ." + Источник.Метаданные().Имя);

(0)КилоГраммы/АвтоМеханизация

Сорри, так делаю всегда. Теперь все? Капец?

ТекстЗапроса = "ВЫБРАТЬ
|    ИсточникДанных.Ссылка,
|    ИсточникДанных.Дата,
|    ИсточникДанных.Номер
|ИЗ
|    #ИсточникДанных КАК ИсточникДанных
|ГДЕ
|    &ИсточникДанныхУсловие";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "#ИсточникДанных", ТекстЗапросаИсточникДанных);
Запрос.УстановитьПараметр("ИсточникДанныхУсловие",Истина);
// при необходимости заменяем &ИсточникДанныхУсловие на ТекстИсточникДанныхУсловие

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

PS: Кстати, не испытываю проблем при вытаскивании реального текста запроса отладчиком и при пинании его в консоли запросов.

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

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

иногда да, приходится собирать динамически тексты, но если можно сделать проще, то я делаю проще...

и вообще у вас _разные_ алгоритмы с _разными_ исходными данными сконцентрированы в _одном_ методе. и это подход опытных 1Сников???

Всю жизнь в типовых 7-ках собирался запрос склейкой и по моему не у кого небыло проблем с пониманием.

Зато в 8-ке черт ногу сломит, с ее многостраничными запросами, плюс приколы, как в (0)

(106) программировали с помощью перфокарт раньше и проблем не было, а теперь обленились все...

Склеенные многостраничные запросы это на столько большое зло, что надо запретить склеивать и средние запросы. И маленькие запросы под страхом сожжения, чтоб все забыли, что вообще можно склеивать запросы :)

И вручную тоже запретить писать запросы, а то умников развелось....

(105)
>> и вообще у вас _разные_ алгоритмы с _разными_ исходными данными сконцентрированы в _одном_ методе. и это подход опытных 1Сников???
Нет, у нас ОДИН алгоритм на общий случай (иногда использующий разные исходные данные в зависимости от конкретного случая) сконцентрирован в ОДНОМ месте.

(0) Если бы отдоэсники писали код без потенциальных багов, то еще можно было понять. На вкус и цвет...

Запрос.Текст = СтрЗаменить(ТекстЗапроса, "Документ.АвансовыйОтчет", "Документ." + Источник.Метаданные().Имя);

Где пробел после Документ.АвансовыйОтчет?

А так в 99% это полная херня...

(111) а зачем пробел ? :)

ну да... туплю :) тогда просто цвет :)

(0) Я так часто делал. А теперь это методология? Кто у кого идеи берёт? ;)

Если есть возможность сделать текст запроса, который можно открыть конструктором, делаю это всегда.
Например, есть типовые отчеты с вставками комментариями, которые нельзя удалять, но очень удобно если этот запрос можно открыть конструктором и быстро посмотреть.
Чтобы внести изменения в него и не потерять комментарии, делаю это в конструкторе, там же смотрю текст запроса из которого руками переношу изменения в текст. Потом повторно открываю конструктором чтобы убедиться что правильно перенёс.

но если нужно сделать так:
ВЫБРАТЬ * ИЗ ВЗ (<текст старого запроса>) КАК ВЗ
то быстрее сделать это руками и потом открыть конструктором.

(0) нормал написано.

(98) а конструктор вскроет?

(114) Да, кстати, насчет "ВЫБРАТЬ * ИЗ ВЗ (<текст старого запроса>) КАК ВЗ",
я что-то даже не знаю, как это сделать конструктором. Вернее сказать, не пробовал.

(116) жмём кнопку "запрос", "изменить", печатаем  выбрать * ИЗ ({ctrl-end} как ВЗ

всё равно удобнее, чем в модуле печатать и "|" расставлять

Нубский вопрос(я семёрочник): Нельзя было вместо (0) написать Ссылка.Дата ?(!!!)

(118) Как раз недавно обсуждалось:
v8: Анализ кода: Неужели так быстрее?

(117) да, несколько быстрее

На axforume Mazzy уже язвительно прошелся по данному вопросу. С точки зрения специалиста по Аксапте сам объект Запрос, предлагаемый 1С, ущербный. "У них" это класс, в котором можно отдельно инициализировать и менять разделы запроса, при этом осуществляется контроль корректности. Это как если бы в 1С было можно:


Запрос.From[0] = Документы. АвансовыйОтчет;


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

(121) да уж, Запрос.From[0] = Документы. АвансовыйОтчет вроде и красиво, да можно представить какие страшные ограничения на запросы это накладывает. А соединения, виртуальные таблицы, подзапросы ?

(122) Практически тот же коструктор, только програмно

(122) >>какие страшные
жуть какая, такой прогрессивный 1с и такая ущербная акцапта.

(122) все это можно отрабатывать атрибутами класса. Например, подзапрос - ссылка на другой объект класса Запрос.

(124) + Полностью согласен.

(125) К чему такие глупости есть же стрЗаменить() ???

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

(0) БрЕД