Добрый день,

Как правильно создать и хранить на сервере таблицу значений?
Требуется при открытии формы создать на сервере несколько таблиц значений и манипулировать ими пока форма открыта.

Передача данных с клиента на сервер и обратно решена, в этом вопроса нет.
А вот с хранением ТЗ что-то не получается. Пробовал использовать реквизит формы -- он передается на клиент, сериализуется -- мне это не нужно. Пробовал описать переменные в модуле формы с директирой &НаСервере -- значения обнуляются между действиями пользователя. Пробовал создать на клиенте временное хранилище и на сервере поместить в него таблицу значений -- содержимое временного хранилища тоже исчезает.
---
Пробовал создать на клиенте временное хранилище и на сервере поместить в него таблицу значений -- содержимое временного хранилища тоже исчезает.
Это потому, что ты при создании объекта временного хранилища не указал идентификатор формы. Когда укажешь - время его жизни будет синхронизировано с временем жизни формы.
ЗЫ. ПоместитьВоВременноеХранилище(ТЗ, УникальныйИдентификатор);
Где "УникальныйИдентификатор" в контексте УФ - системное свойство самой формы.
---
А при помещении во врем хранилище - указываете идентификатор формы в параметре Адрес?
ПоместитьВоВременноеХранилище(<Данные>, <Адрес>)
---
Да
В процедуре ПриОткрытии() я поместил во временное хранилище пустую строку, запомнил в реквизите формы ее адрес, вызвал сервер и на сервере поместил по этому адресу ТЗ.
---
Пробовал создать на клиенте временное хранилище и на сервере поместить в него таблицу значений -- содержимое временного хранилища тоже исчезает.
Это потому, что ты при создании объекта временного хранилища не указал идентификатор формы. Когда укажешь - время его жизни будет синхронизировано с временем жизни формы.
ЗЫ. ПоместитьВоВременноеХранилище(ТЗ, УникальныйИдентификатор);
Где "УникальныйИдентификатор" в контексте УФ - системное свойство самой формы.
---
О! Это похоже на решение. Недочитал я про уникальный идентификатор.
---
Да. Это то, что нужно.
---
Если бы люди умели читать справку, то не развозили бы демагогию.

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

Доступность:

Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).
Возможен обмен с сервером. Сериализуется. Данный объект может быть сериализован в/из XDTO. Тип XDTO, соответствующий данному объекту, определяется в пространстве имен {http://v8.1c.ru/8.1/data/core}. Имя типа XDTO: ValueTable.

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

Это не правильное решение. Т.к. в любом случае, если вы попытаетесь с сервера передать таблицу значений на клиент. Неизбежно получите ошибку

Ошибка передачи данных между клиентом и сервером. Значение недопустимого типа.
по причине:
Ошибка преобразования данных XDTO:
НачалоСвойства: ret Форма: Элемент Тип: {http://www.w3.org/2001/XMLSchema}anyType
по причине:
Ошибка отображения типов:
Отсутствует отображение для типа '{http://v8.1c.ru/8.1/data/core}ValueTable'

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

```1c
    ПоместитьВоВременноеХранилище(ТЗ, УникальныйИдентификатор);
```

После закрытия формы табличка во временном хранилище вытрется.

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

Пример записи в табличку:

```1c
    &НаСервере
    Процедура Команда1НаСервере()

    НоваяСтрока = Табличка.Добавить();
    НоваяСтрока.КолонкаТаблицы = "Данные";

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

пример чтения

```1c
    &НаСервере
    Процедура Команда2НаСервере()

    Для Каждого Стр Из Табличка Цикл
    Сообщить(Стр. НоваяСтрока.КолонкаТаблицы = "Данные";);
    КонецЦикла;

    КонецПроцедуры
```
---
Создайте реквизит формы.
Далее если будете манипулировать данными не в контексте формы:
РеквизитФормыВЗначение()
.... манипуляции...
ЗначениеВРеквизитФормы()

Если в контексте формы - то обращаетесь к таблице напрямую
---
Это сейчас так делается? О, ужас!
---
может тогда огласите саму задачу, а не выбранный для решения инструмент?
---
Задача: Пользователь открывает форму. В это время сервер подключается к стороннему ресурсу и берет оттуда данные.
Далее пользователь интерактивно "копается" в этих данных: что-то выбирает, что-то еще запрашивает.
В это время надо помнить какой-то объем ранее полученной информации. Удобнее всего представить ее в виде нескольких таблиц значения. Пользователь для выполнения своих манипуляций получает меньший объем информации -- для обмена между сервером и клиентом достаточно строк и пр. примитивных типов. Но сервер должен помнить больший объем информации.
---
Но сервер должен помнить больший объем информации.А зачем тут сервер?
---
А как иначе? Информации много. Не тонкому же клиенту ее обрабатывать?
---
Информации много. Не тонкому же клиенту ее обрабатывать?На сколько много? Тонкий клиент ее обработает быстрее, чем сервер (есть такое мнение, ибо скорость файловой, как известно, часто быстрее, чем скорость серверной базы при одном клиенте). Таблицы в таком случае можно просто хранить в реквизитах формы.
---
Таблицы в таком случае можно просто хранить в реквизитах формы.
Фига себе добрый совет. Контекст формы - это не мусорная свалка. Его потом по сети гонять. Не стоит его раздувать без необходимости.
---
вот, сразу видно, что ето-то что-то недопонимает.
1. Зачем гонять контекст формы по сети? Нет серверных вызовов - нет гонок по сети.
2. Клиент данные формы может обработать быстрее, чем сервер, т.к. серверу как раз и придется его получить от клиента, обработать и передать назад клиенту, чтобы отобразить пользователю. Непонимать это, на мой взгляд, невозможно, но некоторые, как я посмотрю, умудряются.
---
Сам дурак.
1. Тут рассматривается решение как раз без синхронизации контекста - данные, которые нужны только для серверных расчетов - на сервере и остаются, не передаваясь на клиента. ТС с того и начал что эти данные на клиенте нафиг не нужны.
2. Если ты на клиенте запихал в контекст кучу изменений данных - рано или поздно им на сервер придется заехать. Непонимать это, на мой взгляд, невозможно.
---
А это все оттого, что Вы не читали, что хочет топикастер. А хочет он вот этого:
Задача: Пользователь открывает форму. В это время сервер подключается к стороннему ресурсу и берет оттуда данные.
Далее пользователь интерактивно "копается" в этих данных: что-то выбирает, что-то еще запрашивает.
В данном случае запрашивать данные может и клиент. Сервер тут не нужен совершенно. Но если на сервере есть какой-то приватный ключ, то тот же топикастер пишет, что проблем с передачей данных между клиентом и сервером у него нет. Получил, передал, работай на клиенте - нечего контекстные вызовы юзать.
---
Я-то как раз читал.
"Пробовал использовать реквизит формы -- он передается на клиент, сериализуется -- мне это не нужно"
"Пользователь для выполнения своих манипуляций получает меньший объем информации -- для обмена между сервером и клиентом достаточно строк и пр. примитивных типов. Но сервер должен помнить больший объем информации"
ЗЫ. Сильно подозреваю, что часть исходных данных он держит на сервере не в типах 1С. А на интерактив клиенту передается только необходимый минимум - агрегаты, отборы, etc.
---
он передается на клиент, сериализуетсяЭто все фигня. На сервер у него данные приходят с внешнего источника, поэтому особой разницы нет, где их получать. И если нет разницы, а работает с данными пользователь (все-равно смотрит их и прочее), то не стоит грузить этой информацией сервер приложений.

Вы смысл попытайтесь уловить, а не просто отстаиванием своей неверной точки зрения заниматься.
---
Вы смысл попытайтесь уловить, а не просто отстаиванием своей неверной точки зрения заниматься.
С языка снял.
Стучаться с клиента к внешним источникам? Внедряйте такое у себя. Мне такого не надо.
"поэтому особой разницы нет, где их получать" - очень смелое предположение. Тонкий клиент элементарно может не иметь физического доступа к внешнему источнику данных.
---
Тонкий клиент элементарно может не иметь физического доступа к внешнему источнику данных.Обычно как раз сервер защищают так, чтобы он не имел лишних связей с внешним миром, а для конкретного пользователя определенных внешних ресурсов открывают соответствующий порт. Но это только у тех, кто заботится о безопасности. Согласен, что подобный подход в кругах андеграунда может считаться моветоном.

Если пользователь работает с данными, то функции сервера ограничиваются двумя:
1. Прочитать данные из СУБД.
2. Сохранить данные в СУБД.

Все. Для остального сервер не нужен.

Если пользователь не работает с данными, а работает с ними некоторый регламент, то, конечно, обработка всего массива данных ложится на сервер приложений. При этом все прекрасно знают, что клиент-серверный вариант работает медленнее, чем файловая база.
---
Обычно как раз сервер защищают так, чтобы он не имел лишних связей с внешним миром, а для конкретного пользователя определенных внешних ресурсов открывают соответствующий порт. Но это только у тех, кто заботится о безопасности.
А с чего ты внезапно решил, что речь о небезопасном источнике данных с обратным доступом способным заэксплойтить или задедосить? Такую экзотику еще поискать. Чаще всего используется исключительно чтение по запросу из доверенного источника по безопасному каналу.
И централизованный доступ к такому источнику, не зависящий от клиентского окружения является стандартной практикой с очевидными плюсами.
Но согласен, что подобный подход в кругах андеграунда может считаться недостаточно черезжопным.
---
И централизованный доступ к такому источнику, не зависящий от клиентского окружения является стандартной практикой с очевидными плюсами. Плюсы только в том, что любой юзер с помощью сервера может обратиться к этим данным. А если данные конфеденциальные?

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

Если мы сохраняем данные во временном хранилище, то это у нас что? Это временный файл, сохраняемый на диск сервера, на котором, обычно, отключен кеш на запись - используется или кеш контроллера SCSI (RAID), или SSD-диск, который в принципе работает быстро (во втором случае имеем лишнюю никому не нужную запись, уменьшающую ресурс диска, но это от размера данных зависит).

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

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

НО! Если с данными в любом случае работает пользователь, то, если не вызывать серверных процедур, обмена между сервером и клиентом не будет. И если данные влезают в память клиента, то серверные функции и процедуры (по крайней мере контекстные) совершенно не нужны. Более того, серверные процедуры и функции будут работать медленнее аналогичных на клиенте, т.к. зачастую частота процессора на сервере невелика.

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

В (4) описание задачи такое:Пользователь для выполнения своих манипуляций получает меньший объем информации -- для обмена между сервером и клиентом достаточно строк и пр. примитивных типов. Но сервер должен помнить больший объем информации.
Но при этом необходимо понимать, что эти все большие данные на сервере не хранятся - они запрашиваются из внешнего источника. Т.е. по заведомо более медленному каналу, чем канал клиент-сервер. Есть ли смысл экономить на обмене между клиентом и сервером, при этом на сервере получать вообще все данные из какого-то внешнего ресурса (полагаю, это не внешний источник данных, а какой-то интернет-ресурс).

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

С учетом того, как сформулирован вопрос, становится ясно, что топикастер - программист начинающий и, соответственно, может и не знать, что с таблицей формы можно работать на клиенте.
---
Левый вход на левый выход - очень редкий класс задач, решаемых с помощью 1С. Типовые задачи все же требуют запись в базу данных. А значит, без передачи данных на сервер не обойтись.
Готов согласиться с тем, что за любым чихом бегать на сервер - распространенное заблуждение. Я его не разделяю.
Но все остальное - очень сильно зависит от контекста конкретной бизнес-задачи. Минимизировать серверные вызовы почти до нуля не получается почти никогда на реальных задачах.
И я с ранних релизов с большой опаской отношусь с тяжелому контексту формы. Уже проделана большая работа над ошибками, но осадочек остался.
Поэтому я вполне понимаю ТС в его стремлении предельно разгрузить контекст формы и разделяю его.
Лучше я рискну парочкой нетяжелых серверных вызовов, чем пойду на риск синхронизации тяжелого контекста.
---
Лучше я рискну парочкой нетяжелых серверных вызовов, чем пойду на риск синхронизации тяжелого контекста.Вот я сейчас занимаюсь разработкой некоего достаточно сложного функционала по парсингу огромного количества связанных друг с другом XML и XSD файлов (таксономия XBRL). Суть задачи в том, чтобы все это прочитать, дать к этому доступ и потом сохранить в базе данных. Так вот 100% чтения XML и XSD у меня реализовано на клиенте, при этом если при чтении вызывать хоть один серверный вызов (без контекста, конечно же, ибо общий объем файлов - 250 MиБ), то это равнозначно запросу в цикле - очень сильно увеличивает время парсинга (даже в файловой базе, когда некоторым кажется, что серверный бесконтекстный вызов ничего не стоит). Т.е. цена одного безконтекстного вызова серверной функции разложения строки на подстроки, например, может превышать 10 вызовов клиента для проведения той же операции (и это даже на файловой базе). Поэтому я не удивляюсь тормозам управляемых форм, когда их разработкой занимаются люди, мало что в этом понимающие.
---
"Один серверный вызов" <> "один серверный вызов в неепическом цикле"
А твои плоские намеки на низкую квалификацию оппонента, мягко говоря, утомили.
Сворачиваю дискуссию.
---
"Один серверный вызов" <> "один серверный вызов в неепическом цикле" Именно об этом я и говорю.
А по поводу догадок - то это ты относишь к себе, а не я. Я просто замечаю, что у некоторых людей управляемые формы работают плохо. И причина - как раз в этом. Просто есть у людей дурацкая привычка по любому поводу лазить на сервер, а этого не нужно в 90% случаев (если не в 99%).
---
"Если параметр не указан, помещенное значение будет удалено после очередного запроса сервера из общего модуля, при контекстном и неконтекстном серверном вызове из формы, при серверном вызове из модуля команды или при получении формы"