Добрый день.

Обработка юзает подключение к SQL.

Что то не пойму где мне нужно это подключение "оставить", чтобы его можно было использовать в разных серверных процедурах?

т.е. на кнопарь навесил "подключиться к SQL" - далее серверная процедура формирует это подключение..

на другой кнопарь хочу навесить "выполнить SQL-запрос" - вызываю из нее "Выполнить_SQL_Запрос_НаСервере" - и вот чтобы тут добраться до созданного ранее подключения SQL - его нужно гдето оставить полежать.

Вопрос ГДЕ :)?

В Структуре, помещенной во ВременноеХранилище.
Испортиться через 20 минут, или при перезапуске rphost / переброске пользователя на другой rphost.
Поэтому, перед использованием, нужно проверять.

(1) ух тыж мне.. хотя в целом неплохо...

других вариантов никто не предложит?

(2) В УФ их больше не существует, на сколько я знаю

(1) я вот подумал - если у меня будет выполняться длительная процедура на SQL, а в середине этой процедуры Подключение_SQL  ВременноеХранилище решит самоликвидироваться - будет неприятно

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

хотелось бы что то найти..

(1)  (4) хотя нет, это я ерунду написал, перед длительной процедурой я же получу уже из хранилища подключение..

НО! проверив обнаружил, что не может он во временное COM поместить. Хоть в структуре, хоть без...

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

Так то бы полбеды - создавать перед каждой операцией новое подключение (50 мс времени), НО в процессе работы создаются указатели RecordSet, которые точно должны жить между вызовами..

(7) Если только читать, есть же внешние источники данных в конфигурации, может их попробовать?

(1) "Испортиться через 20 минут"
Вроде не должен испортиться, если адрес указать.

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

(9) увы, хранилище не принимает COM объекты.. только сериализуемые

(1) Дима, как ты COM в хранилище засунешь, оно же не сериализуется

(10) тоже в эту сторону думаю. и тоже кажется, что других методов нет

Почему никто не пишет, что сама по себе затея это адская дурь?

Для подключения к SQL на сервере херова туча методов без хранения COM объекта на сервере

(13) в параметр сеанса тогда пробуй.

(16) Какой параметр сеанса?
Это COM, его никуда не засунешь в сериализованном виде

(16) так же не дает засунуть несериализуемое

(15) см 7

(15) или рассказывай )

(17) зачем в сериализованном?

(18) ну структуру же дает засунуть.

рекомендую подумать про внешние источники данных, временные таблицы и view в MS SQL

(22) И че и че? Че с этим делать-то потом, как ты его через границу перевозить будешь?

(24) ну, не перевозить через границу.

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

(25) А зачем тогда она нужна?
Как ее передать в новый серверный вызов из предыдущего?
Рукалицо

(7) "создавать перед каждой операцией новое подключение (50 мс времени)"
А у меня на пару порядков больше получается, если база типовая БП.

(26) "а по усмотрению сервера и раньше, если например памяти не хватает..." Или даже если хватает. Поэтому отказались от этого и вернулись к ВременномуХрану.

(29) Это ведь тоже костыль, и в какой-то версии сериализация COM-подключения может перестать работать..

(30) Да, костыль, но шли годы...

В общем и целом, _документированных_ способов, чтобы хранить между серверными вызовами несериализуемые объекты в управляемом приложении, нет. К сожалению.
Чтобы это было возможно, нужно вводить возможность фиксации рабочего процесса в серверном общем модуле. Скажем, сделать галку "Фиксировать рабочий процесс", чтобы все обращения к этому модулю выполнялись на том рпхосте, к которому сеанс обратился в первый раз, и в этом случае чтобы глобальные переменные модуля сохранялись между вызовами. Но это противоречит идеологии направленности на большие масштабы.

Кастую TormozIT в ветку

В (1) и (26) уже все сказано

ну то есть про пулы соединений мы даже думать не будем=)

(35) Так есть же попытки на инфостарте. Но до высокой универсальности не доведены.

Не пора ли уже закопать стюуардессу? Откажитесь уже от OLE/COM/ActiveX

(37) "При всём богатстве выбора другой альтернативы нет" (с) реклама 90-х

(37) Откажитесь от винды, ибо вся она построена на COM начиная с Vistы.

(39) Да дело скорее не в этом, а в том что 1с не предоставляет иного механизма для обращения к ИБ из сторонней программы, не требующего адаптации подключаемой конфигурации.

(40) Других вариантов то и быть не может.

(41) Если речь о подключении из любой программы - то да. Если же речь о подключении из одной базы 1с к другой - то можно придумать интерконнект на уровне прикладной модели.

(43) Ну я о подключении из любой программы - даже ms sql ничего кроме COM модели не предлагает.
А между 1С - это да, можно было бы придумать что то более элегантное, чем подгружать 1.5 Гб-а метаданных на каждое COMподключение.

(42) Все эти веб-сервисы нельзя считать прозрачным доступом к базе. Это скорее "настройка взаимодействия".

(44) По поводу тормозной загрузки метаданных, тут проблема в том что метаданные хранятся в блобах, которые надо парсить. Если бы хранились в виде нормализованного набора таблиц, всё было бы намного быстрее.