Получить Из Временного Хранилища #733170

Приветствую! Создаю обработку, хочу передать данные с сервера на клиент, но говорит следующее: {Обработка.ЗаписьФайла.Форма.Форма.Форма}: Ошибка при вызове метода контекста (ПолучитьИзВременногоХранилища)          Выборка = ПолучитьИзВременногоХранилища(ВыборкаВХ); по причине: Ошибка получения значения из временного хранилища по причине: Ошибка передачи данных между клиентом и сервером. Значение недопустимого типа. по причине: Ошибка преобразования данных XDTO: НачалоСвойства: {    Форма: Элемент    Тип: { по причине: Ошибка отображения типов: Отсутствует отображение для типа '{' &НаСервере

Таблицу значений нельзя передавать на клиент

охрень, чуть мозг не вывехнул от кода

А чего бы на сервере все не сделать?

Да можно и на сервере, это просто эксперимент и больше всего интересно почему не удается получить из ВХ.

Потому-что . ТЗ не модет существовать на клиенте, ТЗ на клиенте - это сконвертированные в данные формы записи.

Вот чувак предлагает решение:

Вот это полная бредятина. Еще можно массив многомерный сделать. А зачем? Зачем передавать на клиент данные, которые там нафиг ненужны?

Прекрасное решение.

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

Мы сами знаем что вам нужно, а что нет (с) 1С

Ну давайте на старенький планшет ТЗ передадим с овер 9000 строк и колонок. Ну-ну... Это нам так надо.

Хреновый пример. Точно также на планшет можно передать 9000 строк и колонок в составе ДанныеФормыКоллекция

ДанныеФормы целиком на клиент не передаются.

Тут срабатывает правило

Причем где-то на 10-12 пользователе, работающем с такой таблицей, сервер 1С двинет кони.

Это не помешает пользователю отскроллить таблицу, поимев ее полностью на клиенте + нехилые тормоза сервера 1С

Точно также можно зашарашить в ДанныеФормы 100000 строк и  дождаться 1-ого скролла около минуты.

Типа такого на клиенте нет

м?

Это я к чему, , говорю. Это я говорю к тому, что не всегда правило работает, и иногда надо мыслить головой, а не наборами правил и идеи типа - отлично работают, когда данных мало и большое количество не предвидется. Вот и в своей методичке ты отработал по шаблонам, не умудрившись подумать. Рекомендую поправить:

у!

д

Вместо временного хранилища используй ЗначениеВСтрокуВнутр и ЗначениеИзСтрокиВнутр

Спасибо, попробую!

Класс!

И что на клиенте появится ТЗ?

Голь на выдумку хитра...

На кллиенте нет такого метода (((

Не все клиенты одинаково полезны. Клиент должен быть толстым)

Вот тебе методика по шаблонам с объяснениями: специально еще раз написал.

Хехе, шутник.

В первой статье первый запрос говорит о том, что вы не понимаете механизьма регистра остатков. Правильный запрос выглядит примерно так:     Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары     Товары.Номенклатура,

Конечно, на экзамене по Спецу любой получит двойку.

несущественное улучшение.

Пфф. Улучшение, которое убирает 1- внешний цикл. Улучшение, которое позволяет сократить на порядок обращение к таблице остатков. По шаблону количество обращений будет n^2, где n-число строк ТЧ товары. По варианту - всего n обращений.

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

какой внешний цикл?

Ты какой метод соединения предполагешь?

Это он про план запроса на sql-сервере в который мутирует запрос 1С.

nestep loops

Единственное что на вложенной выборке нет индекса, но если меньше 100 записей то ваще не влияет

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

А где неоперативный то момент? в этом то и суть хоть и несущественная

Шта? У тебя - на оперативный. Счаст вся типовота считает остатки на оперативный, насколько я помню (могу и ошибаться)

Счаст ради "Высшей справедливости" найду док с 1000 строк

И чего, мне в методической статье описывать все варианты с точки зрения оптимальности на сервере sql? Тема - не эксперт по технологическим вопросам.

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

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

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

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

Нестед луп - это вложенный цикл. Что в нём такого нечестивого?

Я был бы рад, если тысячи мыслили по рекомендациям 1С, а де делали запросы в циклах, получение представления отдельно и предупреждений при проведении.

На 1021 строке nestep loops превращается в mergejoin По шаблону - 2 mergejoin-а, у меня - один. Да, вот теперь выигрыш не такой критичный.

Ты мне лучше скажи, почему условие (А,Б) в (ВЫБРАТЬ А,Б Из Х) выполняется медленнее чем А = Х.А и Б = Х.Б? Я понимаю что медленнее, но почему?!

это особенности самой СУБД. Оператор in - вообще довольно медленная штука. К тому же, по сути, оптимизатор запросов превращает in в join. А по поводу холивара с тов. Ежовым - я не гуру, но у вас, имхо, у обоих неоптимально. Надо бы сначала поместить выборку из виртуальной таблицы во временную и потом по соединяться с ней. Полностью согласен с книжкой "эксперт по технологическим вопросам, цитирую "виртуальные таблицы.... могут разворачиваться в подзапросы при трансляции в язык СУБД...."

На опыте во многих сценариях Left Join  предочтительнее EXISTS и In

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

Сделай текстовый документ на сервере, а не на клиенте и передавай на клиент его.

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

59+

Когда 1С наконец-таки прикрутит в язык запросов инструкцию для того КАК соединять (аналог ключевых слов sql) - это будет радость и веселье

Ну это будет в версии 10.3.12.5987375.