Создаю форму в тонком клиенте, создаю реквизит формы типа "ТаблицаЗначений".
Где хранятся данные этой таблицы? На клиенте или на сервере?
Если я делаю поиск в этой таблице, происходит два вызова сервера (видно в информационном окошке) с довольно большой задержкой. Это нормально?

в памяти

(1) Да вы что! А я-то думал, что в мышке!
В памяти сервера или клиента?

(2) и в памяти сервера и в памяти клиента, ведь экземляров формы как раз два - на сервере и на клиенте.

давай драцца, а то скучно - все бухие, а я даже не подлечился

(3) Тогда вторая часть вопроса.
При поиске строки два вызова сервера. Обмен данными? Зачем, если я выполняю только поиск, без изменения данных, причем в процедуре &НаКлиенте?
И откуда задержка в 2-3 секунды, если в таблице чуть больше ста строк на 10 колонок?

(4) не ври мне, Метод НайтиСтроки() типа "ТаблицаЗначений" в режиме тонкого клиента может быть выполненен только в вызове серверного метода.

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

ну или выражайся грамотно, например так

"Я выполняю поиск посредством метода НайтиСтроки() относительно ДанныеФормыКоллекция и очень негодую по поводу вызова сервера - памагити"

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

(5) не вру

&НаКлиенте
Процедура ПриИзмененииЭлементаФормы(Элемент, Знач АвтоОпределениеСотовогоПровайдера = Ложь)
   Отбор = Новый Структура("ИдПровайдера",ВыбПровайдер);
   Если ТабПровайдеров.НайтиСтроки(Отбор).Количество()>0 Тогда
       СтрокаПоискаТЗПровайдеров = ТабПровайдеров.НайтиСтроки(Отбор)[0];
   КонецЕсли;
<...>
КонецПроцедуры;

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

(8) у него бодун

(8) так у тебя два раза обращение и идет
а так как требуются актуальные данные то видимо идет обращение к серверу два раза

(9) он же сказал "давай драцца". Вот я и машу, чем могу. В данном случае - кодом.
Кстати, если данный фрагмент воняет - можете подсказать, не обижусь :)

неоптимально
тебе отлично подойдет запрос к ТЗ на сервере с возвратом результата серверной функции

хотя что там за <...> ?

(13) там уже вывод данных и обработка других случаев
Если Элемент=Элементы.Поле3 Тогда
...

(11) хотя бы так

Отбор = ТабПровайдеров.НайтиСтроки(Новый Структура("ИдПровайдера",ВыбПровайдер));
Если Отбор.Количество()>0 Тогда
   СтрокаПоискаТЗПровайдеров = Отбор[0];
КонецЕсли;

(14) то есть по сути именно СтрокаПоискаТЗПровайдеров как строка ТЗ не используется ?
тогда если нужны данные из строки на чтение то оптимально запрос на сервере к ТЗ и возврат полученного результата
то есть еще раз - максимально все обработчики данных делать на сервере

(15) Разница, я так вижу, только в том, что структура Отбор не создается и не хранится в памяти.
(16) Ой мама... Я попробую, но таких вызовов в обработке уйма, пересмотреть все займет время. Не теряйте меня и, желательно, не теряйтесь сами.

"у меня обратная задача - максимально вынести данную обработку на клиент, чтобы к серверу обращалось только за созданием документа."

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

(17) разница еще в том что ты ищешь строки ТОЛЬКО ОДИН раз - это оптимально
придется пересмотреть ПОДХОД - иначе в контексте 8.2 будет сложно переучиваться
я это наблюдаю на коллеге который застрял в 8.1 )) у него в голове только толстый клиент

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

Агрумент, мол, НайтиСтроки() для данных формы коллекции работает медленно - ваще неадекватен, ога)

если вызов к той же ТЗ то вообще все можно одним запросом реализовать
в разумных рамках помогу но если надо переписывать всю конфу то это дорого ))

А какая разница "&НаСервере" и "&НаСервереБезКонтекста"?
Когда лучше использовать один и когда второй?

(19) ты я вижу здорава переучился и лихо насмотрелся г-кода в первых типовых на УФ, какого-только бреда там не встретишь)

Вот сейчас пишу функцию, которая получит из ТЗ данные строки и передаст мне, как структуру.
Мне нужен контекст?

в методы с директивой

НаСервереБезКонтекста

выносят аглоритмы которым не нужны данные формы,
пример расчет факториала)

(20) это ты неадекватен) а только на днях подобное обращение переписывал из-за тормозов

(25) Например вот эти три я точно могу без контекста делать, так? ДатаСервера = функция глобального модуля.
&НаСервереБезКонтекста
Функция ДатаСервераТК()
   Возврат ДатаСервера();
КонецФункции //ДатаСервераТК

&НаСервереБезКонтекста
Функция ЗначениеИзСтрокиВнутрТК(Значение)
   Возврат ЗначениеИзСтрокиВнутр(Значение);
КонецФункции

&НаСервереБезКонтекста
Функция ЗначениеВСтрокуВнутрТК(Значение)
   Возврат ЗначениеВСтрокуВнутр(Значение);
КонецФункции

(26) попахивает кривым проектированием тогда)

(22) в идеале всегда насерверебезконтекста и передавать нужное параметрами процедуры\функции - ЭТО ОПТИМАЛЬНЕЕ
просто насервере - когда тебе надо передать весь контекст формы по каким-то причинам (чаще от лени))
форма есть на сервере и на клиенте - между ними качаются ее данные

(0) По-хорошему - ненормально.
(22) Всегда, когда возможно - второй (когда нет работы с данными формы напрямую). Тогда идет "легкий" серверный вызов без прогонки синхронизации данных формы.

(23) мало ориентировался на типовые ибо когда начинал сыро там было
все по книжкам и методами проб\ошибок
в книжках кстати рекомендации и были

(24) пригодится

(28) ну дык не без этого)) сам насгал - сам убрал)

когда начинал некоторые места переписывал по десять раз пока не понял как именно надо

(27) а дата сервера что делает?

(30) + Хотя вру. Это нормально, ибо фича документирована: "Вызов метода выполняет обращение к серверу."

(30) аха вот чувствуется опыт)
у меня недавно вот с этими строками на клиенте тормоз получился всего на паре сотен строк
вроде бы тоже - пустяк

(27) если насерверебезконтекста работает без ошибок то можно применять ))

(37) Я не про опыт, а про то, как это должно быть в идеале. Поиск в клиентской структуре на стороне клиента не должен вести к серверным вызовам. Но раз документировали, то ладно :)

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

&НаСервере
Функция ДатаСервера() Экспорт
   Возврат ТекущаяДата();
КонецФункции

Ее приходится вызывать по цепочке:
на клиенте ДатаСервераТК()
на сервере в форме - уже ДатаСервера()

(40) если дата нужна для документа при создании то присваивай в процедуре присозданиинасервере
сэкономишь на вызовах сервера

Можете сэкономить время на поиск, как в запросе обратиться к реквизиту формы?
ВЫБРАТЬ
|    *
|ИЗ
|    ТабПровайдеров //??????????????
|ГДЕ
|    ИдПровайдера = &Ид

(39) это было бы идеально да
но мы живем в одинэсе )

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

(42) Окстись. Запросы, они к БД. Можно, конечно, во временную таблицу загнать. Но зачем??

(44) для чего нужны другие вызовы ?

(46) Для передачи даты налево. Это обработка по приему платежей в ОСМП. Это не так важно, забейте.

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

(48) реквизит типа ТаблицаЗначений на сто строк - в параметр запроса длиной в пять строк???
Я начинаю сомневаться в такой оптимизации.

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

(49) не сомневайся - делай )

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

(52) О да. Перегрузка туда-сюда сотен тысяч строк - чудеса масштабирования.

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

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

понимая что сейчас бы переписал все иначе совершенно

(55) Я о том, что для локального поиска в таблице значений по простым критериям - глупо использовать временные таблицы. Если упрется в производительность - индексы добавит и всё. Это гораздо более правильное и масштабируемое решение будет.

(53) сервак же резиновый и все сделает - у него голова большая.

это ж в каких книжках рекомендуют такую чушь?

(57) меня бесит что просто Найти похерили на клиенте
вот ее бы могли бы оставить + без обращения к серверу

(57) для локального поиска Сtrl+F ))

странная полемика пошла.
А давайте каждый напишет, как он бы переделал фрагмент (8) и разберем код каждого?

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

(59) Велика беда. Для легких поисков можно и без него обойтись - тупым обходом.
Я тяжелые поиски сам бог велел на сервер выносить.

(58) для хорошего сервака плевое дело

(61) извини - это дорого )

(62) автор я.
У меня есть таблица с 20-ю полями. Мне нужно найти в ней одну строку и получить все значения полей из нее.

(64) Вот только не надо тогда лапшу на уши вешать про масштабируемость, если вся твоя масштабируемость упирается в железо, которое сроет все твои косяки.

(63) ну нафиг - циклы это отрыжка какая-то
хотя... если именно сэкономить сервер

(66) Если речь о сотне строк и перебор не ведет в серверным вызовам (я просто в УФ не настоящий сварщик) - я бы просто перебрал на клиенте. Должно быть очень быстро, если 1С еще где-то не потоптались.

(66) по быстрому (15) - на будущее - запрос
хз какие в будущем условия будут - в найти ты только равенства можешь отобрать

(67) нет блин - надо всю работу на клиент переложить причем с голимой встроенной синхронизацией с серваком
+ еще за вариант с обходом в цикле надо сразу к стенке по хорошему ставить ))

мой вариант (8)

&НаКлиенте
Процедура ПриИзмененииЭлементаФормы(Элемент, Знач АвтоОпределениеСотовогоПровайдера = Ложь)
   
   // Отбор для ДанныеФормыКоллекции
   ОтборДфк = Новый Структура("ИдПровайдера", ВыбПровайдер);  
   мДфЭлКол = ТабПровайдеров.НайтиСтроки(ОтборДфк);
   
   Если мДфЭлКол.Количество() Тогда
       СтрокаПоискаТЗПровайдеров = мДфЭлКол[0];
   КонецЕсли;

КонецПроцедуры;

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

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

Я поржал. Над собой, не парьтесь. Тему можно закрывать.
Решение проблемы оказалось в том, что затронули слегка и чисто случайно.
В (27) указаны две процедуры, которые и давали задержку. Они вызываются просто немерено в обработке, и после указания "&НаСервереБезКонтекста" они стали выполняться неизмеримо быстрее.

(72) баня) (15)

баня=баян

(73) вероятно) потом как-нибудь пересечемся еще )) когда повсеместно будет 8.2

(76) ошибаетесь. Отличия от моего кода:
В (15) структура отбора не хранится.
В (72) только то, что нет сравнения на >0.

(74) Простой перебор небольшой коллекции даже убитую нокию не затормозит.

(79) накуа отбор хранить? он сразу дематериализуется когда становится ненужен
сравнения нет - наверное описка

(80) + А вот накладные расходы на серверные вызовы и синхронизацию контекста могут быть весьма ощутимые.

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

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

в

// ....
...

они могут пригодиться, не могут убиваю сразу

(84) В данном случае Экспериментатор прав - отбор хранить не нужно, он не используется позже.

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

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

(84) кстати как убиваешь структуру? переприсвоением?

(87) экраны разные бывают) По этому правилу для 1024х768 задолбаешься оптимизировать.

(0) ТС - потом если сделаешь померяй отладчиком что быстрее на объеме найтистроки или запрос ?
хотя я думаю выбор ты уже сделал)

(89) конечно 1920х1080

(83) Я тоже х.з, ибо на тонком клиенте опыт небольшой. Но предыдущий опыт подсказывает, что заведомо легкие вещи нет смысла гнать на сервер. Надо взвешенно подходить в каждом случае. Перестраховка на каждом углу она ведь тоже не даром - увеличение латенси на простейших вещах из-за лишних серверных вызовов плохо сказывается на юзабилити. О производительности клиента думать конечно надо, но не надо забывать и о качестве канала. Это сплошь и рядом играет более важную роль.

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

Если вы в УФ используете тз, именно тз или дз с тысячами строк и более, а не тч, дсписок - то это ваше кривое понимание и кривое проектирование формы, которое вынуждает вас заставлять сервер обрабатывать виртуальные данные формы, а не таблиц БД.

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

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

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

(95) кратко опиши мне задачу в условных терминах(Справочник.Дыни например) для которой необходимо разполагать на УФ таблицу значений с объемом данных в тысячи или десятки тысяч строк.

Естественно на таких объемах слабый клиент будет подтормаживать на поисках и отборах строк.

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

Так опишешь задачу?

(97) Справочник есть справочник. Он хранится в базе, держится естественно на сервере. Вы лучше представьте себе таблицу, которая получается с левого сервера в интернете при начале сеанса работы, и от нее уже отталкивайтесь.
Вы же не будете каждый раз справочник заполнять/очищать?

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

+(99) правда критерии отбора клиент делает заранее до вывода результат в ТЗ но это только сужение поиска

(97) как я понимаю все же одинэс не такие глюпые и выясняют модифицированность данных формы
так что осталось решить только как оптимальнее делать отбор данных из ТЗ

(98) )) я ж говорил ему что задачи бизнеса бывают разные
таблицы только хранят данные а вот выборка по ним может быть весьма витиеватая )

99 точки доставки должны быть некими классификаторм в БД и его состав всегда конечен при создании формы.

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

Грузить же массу данных в некую мифическую тз на форме и потом чесать репу как в ней что-то найти - кривое проектирование)

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

(103) О чем вообще спор? Классификатор, справочник - какая разница? Из них даже ежик будет запросом данные тягать!
Речь идет именно о том, как оптимизировать выборку из ТЗ. Почему использованы ТЗ, я тоже уже объяснил.

(102) вы кроме 1С работали с таблицами БД, сейчас на 8.2. можно представить дсписок произвольным запросом как комбинацию таблиц ТБ, строковых, числовых констант и т.д.,
т.е. одим запросом построить тот же вид пользовательских даныых с которым вы извращаетесь помещая его в тз)

(103) ДС проходили - тормозит
в ТЗ клиенту предоставляется информация о городе доставки, точке доставке, грузополучателе и договоре с клиентом
все это разные таблицы БД
отбор клиент осуществляет быстро вводя различные свойства этих условно говоря колонок
иерархия долго и непонятно для клиента - клиент ОЧЕНЬ разный и его уровень мне не интересен - важен заказ

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

(103) идея вывести критерии отбора в отдельные ТЗ была но сейчас уж пусть как работает так работает )
начнут жаловаться на тормоза надо будет думать

(106) где это обосновано там используется ДС - но у него свои выкрутасы

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

(107) иерархия просто и понятно для клиента если ее показать просто и наглядно.

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

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

(111) в вашей задаче подход изначально неверен - для нее нужен вебсервис, тогда и проблема с громадной тз отпадает

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

(113) расскажите это ОСМП. С ее десятью миллионами терминалов.

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

(0) Данные ТЗ хранятся на сервере в данных сеанса. Для отображения данных ТЗ у клиента, они конвертируются в ДанныеФормы и передаются клиенту. ДанныеФормы <> ТЗ. Обращение к ДаннымФормы (на клиенте) для их перебора или поиска однозначно приведет к серверному вызову.

(116) другого пути - это какого? Господи, задача ограничена:
Факт = Есть ТЗ.
Факт = Есть необходимость найти в ней строку.
Цель - сделать это самым оптимальным способом.

Все! Нет справочников, нет классификаторов и иерархических списков!

(112) тормозов нет касательно именно этой таблицы - по крайней мере жалоб от клиентов не поступает
неожиданные тормоза стали на подобном в (0) случае
когда найтистроки на клиенте вызывали тормоз на паре сотен строк в ТЧ документа
вообще наверное меня можно не принимать всерьез так как УФ используются во всех видах клиентов
+ отладка сервера включена
но в идеале надо чтобы не тормозило во всех видах клиентов чтоб наступило всеобщее счастие ))

(118) Оптимальный способ это вызов контекстной серверной процедуры, поиска в ней данных.

118.

Решение задачи в следующей вашей постановки

"Вы лучше представьте себе таблицу, которая получается с левого сервера в интернете при начале сеанса работы, и от нее уже отталкивайтесь"

Есть факт, что тз на 8.2. - это уже элемент управления данными, а не элемент данных

(120) А если достаточно данных формы? Разве я не могу без вызова сервера обойти представление данных (ДанныеФормыКоллекция)?

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

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

ТС может представить исходные данные как внешний источник данных в 8.2 и по нему уже делать хоть ДС хоть что ??

ТабПровайдеров как получается ?

(122) И это приведет к серверному вызову, так как на стороне клиента ДанныеФормы могут являться лишь частью данных реквизита формы. Для ТЗ это особенно актуально, так как ее данные могли быть изменены и уже не равны ДаннымФормы.

(125) одним ответом сервера ОСМП. Вся сразу. В виде XML, из которого собирается таблица.

(127) большая судя по всему ?

наверное
я бы заполнял некий регистр сведений этими данными
чтобы избежать многократных созданий временных таблиц для запросов к ТЗ
запрос по регистру будет быстр
далее как представить этот регистр на клиенте - дело фантазии разработчика

(128) примерно 100 строк, 20 колонок. я уже говорил.
(129) Эта таблица уникальна у каждого пользователя, а порой - и при каждом запуске.
Кроме этой таблицы есть еще порядка 20 похожих списков от 5 до 500 записей.

(129) И да, пользователей около 100.

(131) Таблицу надо пользователю показывать? Или только выборку из таблицы?

(132) при настройке - надо. При повседневной работе - нет.

юзай пока (15) а потом при необходимости перепишешь

или тоже лаг большой ?

(135) Лаг давно ушел, см (75).
Просто спор уже на принцип пошел - как оптимальнее.

(126) То есть, отображение ТЗ в тонком клиенте идет порционно, подкачивая данные по мере необходимости так же, как и для динамических списков? Понятно, что динамические списки еще и из БД порционно выбирают. Я в части клиент-серверного взаимодействия интересуюсь.

(136) )) не поверишь я только сейчас этот пост заметил - так увлекся )

(137) по моим наблюдениям ТЗ целиком попадает на клиент

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

Я вот тоже не пойму. Нет, я вот в 8.2 пока не силен. Но ТЗ (данные которой используются чисто в форме) - обрабатывать тоже на сервере надо?
Мой моск сломан.

(140) одинэс походу решил воплотить триединство в УФ
клиент, сервер и отображение ))

"чисто формы" нету - матрикс хаз ю )