С одной стороны очень мощный инструмент, с другой все ограничивается низкой производительностью.

Например, хотим вывести поле с ценой напротив каждой номенклатурной позицией. Для справочника в 1000 позиций никаких проблем, для 100 тыщ. будут дикие тормоза, так как срез последних по регистру будет медленно работать.
в 8.1 в событие ПриПолученииДанных можно было в легкую это сделать, так как срез получался для товаров, которые умещались на экране. Правда и отбор нельзя было сделать по цене...

срез - левым джойном на текущую дату?

проверял на 25 тыс., вроде ничего бегало - без РЛС правда, под полными правами

Вот Временные добавят и будет щастье.

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

(1) Там отбор регистра по номенклатуре - во вложенном подзапросе. По всей таблице будет.

(1) Ты про это?
Книга знаний: Срез последних на каждую дату в запросе

(1)Ну да.

(2)Проверял на документах 300 тыщ. все плохо.
(4) Дело в нетупорылом запросе, тут по другому не напишешь.

так, мы так не договоримся.
я так вообще представил себе:
ВЫБРАТЬ
*
ИЗ Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры(Дата) КАК Цены
ПО Цены.Номенклатура = СправочникНоменклатура.Ссылка

ну и фильтр ещё - по виду цены или чему там

(4) УТ 11 погляди, последнии версии. Они от (8)  в подборе номенклатуры отказались.
С

а как на самом деле?

(7) динамическое считывание не влияет никак?

(10) так там в подборе запрос другой был.. не просто цены

(10) они отказались. в итоге люди а акуе от работы с этой конфой. не могут работать без остатков и цен.

(13) Там еще и остатки были.
(12) Нет, если подзапросы используешь. А без подзапросов никуда.

вот я и спрашиваю, накуя? если не работает, типа вывести текущий курс в справочнике валюты?

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

(13) все верно. наворотили условий по соглашениям и т.д. и т.п. Если раньше просто моджно было отследивать особые условия и запрос динамически программно формировать то щаз куй. пока всю систему словий в запрос не вставишь - цены нормальные фиг получишь.
по остаткам так вообще отдельная песня - каждая! фирма нуждается в том чтобы при отборе видеть остатки и те только - кучу сопроводительной информации.
http://www.subsystems.ru/media/k2/galleries/22/RMMprodaz2.png

без того ут11 в принципе для многих фирм не имеет смысла.

Для УТ11 разработку поддерживаю для рмм по продажам
http://www.subsystems.ru/Разработки-1С/Продажи/Рабочее-место-менеджера-по-продажам-для-Управление-торговлей-11

тормозит да. оптимизацией занимаюсь. деваться некуда.

(17) а че его смотреть, СрезПоследих и в Африке срезПоследних.

(20)если запрос простой, как в 8, то тормозов особых быть не должно

(21) в том то и фишка - запросы простые. а тормоза есть! зуже чем в 8.1 было при выводе данных процедурой списка приПолученииДанных.
в 8.2 динамические списки тормозят реально на больших справочниках.

я вообще в шоке. в ут11.05 более менее еще был подбор, в ут11.0.6 его нафиг весь похерили. люди в шоке. говорят реботать вообще нереально.

причем тормоза не только на списках, а в том что они понаделали хрени с характеристиками/упаковками и прочими делами что теперь из за всего того нельзя обычные данные нормально получить. в типовом подборе 7 тысяч строк кода! сотнями проверки вскяие и прочие дела.
а сам подбор стал гораздо хуже и менее функционален чем в ут10.

(6) не, то - космос, ясно, что не взлетит

(0) в 8.1 можно было что угодно сделать и с отборами и с получением данным. А щаз...смирись..

(21) Ну вот с хрена бы не должно?
Посмотри, во что СрезПоследних в профайлере раскладывается.
Один в один (8).

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

плохо. что убрали при получении данных. отличный был обработчик.

как минимум можно было программно вытворять очень много вещей. да и работало стабильно по скорости.

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

P.S. В 8.2.14 не прикрутили, не?

(29) Хорошо, что убрали

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

(31)  как вт спасут???

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

(27) я и так знаю, что такое срез последних, зачем смотреть?-)
(28) тянуться то она будет на сервере

На сервере, но все равно долго. Чтобы выбрать следующие 50 позиций списка, срез последних надо снова делать.

Других вариантов нет. 1С вообще убрала остатки и цены из подбора. типа тока по текущей позиции можете увидеть.
если по списку хотите - болт.

Как вариант текущую цену можно хранить в реквизите справочника номенклатура и выводить именно оттуда. Если требуется в динамический список тащить прошлую цену, то тут уж ниче не поделаешь - срез последних. Думается мне, что это более чем наполовину спасет ситуацию.

(39) думается мне, никак не спасёт=)
в рамках той же УТ 11 - цена для каждого клиента своя может быть.

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

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

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

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

(40) Если для каждого клиента своя, тогда борода. Я УТ 11 не знаю(

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

еще один аргумент что УТ11 еще сырая конфа и рано на неё переходить. в ут10 на 8.2 в обяных формах -никаких проблем вообще. причем данных гораздо больше. как минимум 5 соединений работает и все летает.

(44) то что ты сказал - борода в любом случае. даже без Ут11.
цены в карточку добавлять это сразу двойка в дневник.

а ведь уже 1000 раз пели на тему  "не используйте динамический список там где ему не место"

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

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

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

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

(47)много данных.. открываться будет шопесец.

(50) принципиально не вижу невозможности...

(51) это да.. логично.. зато шарится по списку будет без тормозов...

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

+(53) ограничить выборки?
сделать конструктор подбора, типа:

обработки -> из жести -> из жестяной жести -> обработки мани

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

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

(56) это идиотский вариант. тебе то любой присутствующий спец скажет. по одной простой причине - такого делать нельзя!

(55)чем проще - тем лучше - без мышки сложновато все это делать

(56) кстати да.. пример ЗУП показательный..
при записи в регистр с ценами обновлять реквизит справочника..

что принципиально мешает?

хочешь историю - лазий в регистр..
хочешь актуальную цену - бери реквизит справочника...

хочешь цен больше чем одну но незнаешьсколько - наштампуй реквизитов или сделай табличную часть справочника...

(59) табом..

(58) какие детские комплексы запрещают тебе так делать?

(58) расскажи это разработчикам зупа.. и пользователям желающим видеть текущее подразделение, текущую должность и тд и тп  во ВСЕХ отчетах где есть сотрудник..

(61)наверное, пойдет

(56) подразделение и должность имеют одно значение для одного элемента. тут логично хранение в карточке. Цены сравнивать с должностью я даж не знаю что тебе ответить.....
Ты перепишешь четверть конфы под цену в карточке. убьешь нафиг типовую. Через полгода у фирмы задача изменится! будет две цены! и ты со своим гениальным решением дрочь фирме обеспечишь. Нельзя делать в конфигурации то что заведемо в будущем может оказаться неправильным подходом.

(64) все равно у тебя пользователи по структуре каталогов в справочнике шарятся..

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

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

(65) для тугих: ничего не надо переписывать.. никогда и низачто..

пусть цены лежат в регистре..
но
для работы с динамическими списками где нужно показать ТЕКУЩУЮ цену.. добавляется кусок кода в 10 строк в соответствующий менеджер и вуаля - у тебя в реквизите справочника ВСЕГДА актуальное значение...

(65) см 60

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

(65) какие нахер "четверть конфы под цену в карточке"??? если речь идет про вывод текущей цены в форме подбора.

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

(69) что ты против (60) скажешь?
вполне себе работоспособное решение.. обеспечивает как историю так скорость работы дин.списков...

+

не надо переписывать типовую :)

(71) эээ это же типовое решение...

у тебя есть более оптимальное решение?
предложи, озвучь.. посмеемся вместе..

(67)это не так, если брать, опять же, УТ 11.
т.е. цену определить можно только по условиям соглашения.

(71) обоснуй уже идиотизм решения

(72) то идиотское решение. я уже сказал.

(74) и? принципиальная разница в чем?
в соглашении же штатно сидит табличная часть с товарами/ценами?

что мешает ей воспользоваться

(72) по вашей логике любые данные надо в картчоку пихать! идиотизм.
И чо я в карточку и остатки буду пихать? и заказы? может сразу 150 регистров запихать? в карточку?
Завтра скажут добавить в список из регистра заказов дату - тоже в карточку?
у меня пять соединений.

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

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

+(77) про УТ вообще песня получается..

цены привязаны к соглашению? что мешает при побдоре показывать только их - какое нафиг соединение со всем регистром цен по всем соглашениям?????

(80) какому тупику, какой постановки?
решение универсальное...

Писать в реквизит - глупое решение. Более глупое, чем Срез без фильтра.

(79) я брежу? да это вы два дурака тут бред несете про карточки и реквизиты. бухие наверное.

Я бы за такие методы бы просто выгнал бы сцаными тряпками программиста с работы.

(83) в типовых так сделано..
предложи способ показать актуальное значение во всех отчетах и дин.списках сразу...

переписать все отчеты добавив туда очередное левое соединение?

(85) гы гы...

(77)множество факторов.
т.е. цена не определена для позиции номенклатуры - цена определена для ключа:
Номенклатура+Партнер+Валюта+Ещё чего-нибудь.
И ещё исключения по цене, заданные в ТЧ соглашения

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

(85) Выгони себя сам за открытие формы документа...

(83)ты это самое, не стесняйся, предлагай=)

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

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

что мешает воспользоваться именно этой табличкой?

Вариант - РС ПослениеЦеныНоменклатуры...
Непериодический.

(91) так эта табличка не хранит в себе все цены.
или ты имеешь ввиду следующее: писать туда все цены по соглашению, но это же много

(92) думаешь на больщих объемах разница будет существенна?

(92)мм.. думаю, не спасет=)
т.к. есть ещё условия соглашений

(93) в серьезно задает каждому соглашению цены на ВСЮ номенклатуру ?

(96)вы серьезно задаете?

(95) Я, применительно к КА1.1 смотрю. Нету у нас УТ11. Пока нету.

(96)я не понимаю, как ты её хочешь использовать.

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

(98)не, это другое, там усе проще

(100)надо вопросы последовательно решать

(98) в обычном приложении нету проблем с выводом списков.

(98) вот например для УТ, КА, УПП
http://www.subsystems.ru/Разработки-1С/Продажи/Рабочее-место-менеджера-по-продажам-справочник-с-остатками-1С-УТ-КА-УПП-БП

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

(94) Думаю - да.
Не будет там подзапросов никаких нефильтрованных, и SQL вздохнет спокойно.

Реализуется на 1-2-3, за 5 минут.

В УТ11 на УФ у динамического списка должна стоять галка. тогда по всем соединениям и т.д. по запросам идет запрос тоже только по номенклатуре отображенной на кране.
у (0) проблема в том что при любом раскладе в 8.2 УФ пока что все то работает заметно медленнее чем в обычном приложении.

(104) ниодин менеджер с таким убожеством работать не будет.. этож трындец угребище...

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

(105) на УФ все фильтруется тоже.

А вообще, в свете фразы (36)
<<(28) тянуться то она будет на сервере>>

Я радуюсь, что Розница, а не УПП.
И что мы с Розницей не работаем в принципе.

(107) пипец у тебя выводы. это реальная потребность у большинства фирм.

(108) Вот с хренасебе?

(110) хз.. большинство менедежров по продажам которых видел - стошнило бы от такого решения.. вернее они бы его закрыли бы и не забивали бы себе мозг...

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

(107) Была фишка такая -
"Чтобы была нечеловеческая музыка, все двигалось и играло"...

Счаст найду...

(111) потому что там стоит признак. галочка - фильтровать динамически. это значит что запрос динамического списка работает только по полученному на экран результату.

(113) предметная задача собирать данные остатков и срезов последних по десятку параметров и обновлять это каждые 60 секунд отображая 20ти менеджерам на рабочем столе? :) :) :)

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

(115)
Поставь мне галочку "фильтровать динамически" вооот в этом запросе:

ВЫБРАТЬ
   ЦеныНоменклатурыСрезПоследних.Номенклатура,
   ЦеныНоменклатурыСрезПоследних.Цена
ИЗ
   РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
           ,
           Номенклатура В
               (ВЫБРАТЬ
                   Номенклатура.Ссылка
               ИЗ
                   Справочник.Номенклатура КАК Номенклатура)) КАК ЦеныНоменклатурыСрезПоследних

(109) что сказать, читай ИТС.

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

(117) что мешает по звонку клиента открыть форму ?

что мешает сделать форму подбора в виде отчета на скд?


не ну серьезно.. сидит менеджер - накой ляд ему эти ваши изыски с динамическими формами если для него можно организовать подбор из отчета на СКД ????

а в отчете хоть ужритесь своими соединениями.. хоть сто их сделайте..

в УТ11 в подборе версии 11.0.5
у динамического списка используется запрос который использует порядка 7 соединений с номенклатурой.
осеновная таблица указана - справочник.
Стоит галка - динамическое считывание данных.
Запрос срабатывает по всем соединениям по номенклатуре отобрадженного списка. ты какую то лапшу вешаешь про то что соединение делает запрос по всем данным. это неправильное утверждение.

(121) предложи свои идеи фирме 1С. чо ты меня спрашиваешь.
у нас все замечательно итак работает. и у дргих тоже. все что надо. На УТ11 я не тороплюсь. у кого с ней проблемы - поверь их там помимо сабжа сотни проблем. не только со списками и данными.

(120) Что не так? Ты противоречишь себе же в (108).

(121) да вот именно. вы вообще не в ту степь полезли. причем тут соденинения вообще.
у автора проблема что медленно работает на 100 тыщ номенклатуры. проблема в том что 1С еще не до конца доработала платформу 8.2 для УФ ВОТ И ВСЯ ПРОБЛЕМА.

(125) спорим я могу сделать так что справочник из 1000 позиций будет медленно работать  и в 8.1 ?

(124) я в шоке....у тебя ут11 нету сам признался. а учавствуешь в дискусии с какими то утверждениями.
запусти ут11 и посмотри.

(127) Стена. Ядъ.

(126) накуй оно мне надо? я работаю с клиентами и их конкретными задачами. предметными.
а 1с для меня только инструмент решения этих задач.
сегодня оптимизировал клиенту загрузку в ут11 картинок с объемом 100 000.

(128) вот именно. пойди прими. а то попривыкали понимаешь лезть "поперек батьки в пекло".

(129) отобразил ему все 100 000 картинок на экране?
сделал автообновление оных кажддые 60 секунд?
написал гневное письмо в майкрософт на тему "почему винда такая тормозная" и в интел на тему "почему ваши процы такие тормозные" ? :) :) :)

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