Доброго времени суток, переделываю обработку с обычных форм на управляемые и столкнулся с проблемой. Значение объявленной переменной теряется при переходе между процедурами и функциями. Подскажите пожалуйста как сохранить значение переменной. Условно если я присваиваю переменной значение 2, но в другой процедуре значение переменной неопределенно, как сделать чтобы оно оставалось 2 пока я его не изменю?
Заранее спасибо за помощь
(1) Лучше создать строковый реквизит формы с адресом временного хранилища, в котором хранить кеш переменных, чтобы избежать конфликта миграции значений между сервером и клиентом.
(5) Чем хранение непосредственно в реквизите не устраивает? Зачем плодить сущности без надобности?
Реквизит доступен и на клиенте и на сервере. Никакой передачи нет от слова ВООБЩЕ.
(7) Его можно хранить в клиентской переменной модуля формы или, если использование соединения необходимо только на сервере, его можно поместить в Структуру, которую, в свою очередь, поместить во временное хранилище. Адрес хранилища можно держать в реквизите формы. Такое соединение можно будет получить в несвязанных серверных вызовах.
(6) В реквизите формы можно хранить только значения, которые могут мигрировать между сервером и клиентом. При каждом контекстном серверном вызове происходит передача данных формы, то есть всех ее реквизитов.
Если мне нужна глобальная переменная на сервере, например, Соответствие или ТаблицаЗначений, реквизит формы не подойдёт.
(13) Если обращения к содержимому хранилища на клиенте нет, то нет.
Кстати, это легко подтверждается тем, что ком-соединение можно закешировать во временном хранилище и хранить адрес хранилища в реквизите формы. Мы же понимаем, что никакое ком-соединение невозможно перенести с сервера на клиент.
(14) Если серверов несколько, имхо, не взлетит с комом.
Такая же хрень будет если например взять документ объект - добавить в массив, а массив поместить во временное хранилище.
Если серверов несколько то при получении из временного хранилища на другом сервере в массиве будет неопределено.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).
(13)Конечно не миграция, если в таблице 100 000 строк, и таблица хранится только во временном хранилище, это никак не повлияет на быстродействие работы формы.
Будет и открываться быстро, и любые серверные вызовы отрабатывать быстро.
Если же открыть форму, в которой в таблице в реквизите 100 000 строк, открываться форма будет заметно дольше.
(23) с реквизитом типа Строка тоже можно работать на клиенте. Только как это поможет в работе с Таблицей значений?
Да, работать можно с урезанным функционалом и выгружать в ТЗ на сервере. Только ведь речь не об этом. Если нам не нужны данные на клиенте и работа с ними необходима на сервере в разных серверных вызовах... При каждом контекстном вызове будет много лишних данных передаваться с клиента на сервер и обратно.