Здравствуйте.
В связи с переходом с MDB+MDB на MDB+MS SQL Server, возникла следующая проблема:

Для временых данных использовались общие таблицы, разделённые на сеансы по ключу SessionID. Для определения ключа SessionID велась единая таблица где хосту и полному имени базы приписывался код(счётчик).
Для получения, изменение и удаления данных использовался готовый запрос с WHERE SessionID = getSessionID(). Функция getSessionID() вычисляла SessionID по имени хоста и базы.

Теперь все таблицы и большая часть запросов переехали на SQL Server и требуется вычислять SessionID и в приложении Access и на самом сервере. Для вычисления в приложении ничего менять не требуется. А вот как лучше поступить с SQL Server мне ещё не понятно.
Для запуска хранимых процедур, функций и открытия ADODB.Recordset в модулях используется один и тот же ADODB.Connection, для которого при открытии можно настроить соответствие SessionID и @@SPID. Тогда getSessionID() на сервере будет искать по @@SPID.

Но как быть с прилинкованными как таблицы VIEW?

К сожалению, моё знакомство с MS SQL Server довольно поверхностно, и на возникающие вопросы бывает трудно найти ответы из-за недостатка знания для правильного формулирования вопроса.
studierenВ Access'е на самом деле нет временных таблиц, просто иногда "постоянную" таблицу используют так, как-будто она временная. Поэтому Вы наверное придумали свой "SessionID".Я писал не про временные таблицы, а про временные данные. Для хранения которых и используется постоянная таблица "как-будто она временная". А что-бы определять хозяина порции временных данных в постоянной общей таблице и используется придуманный SessionID.
studierenА вот в MS SQL Server как раз таки есть самые настоящие временные таблицы. Создайте с одной решёткой "#Table" если хотите, чтобы 1 юзер имел дело только со своей временной таблицей, ну или с двумя решётками "##Table", если хотите, чтобы все пользователи могли обращаться к этой таблице, пока она не удалилась. В чём проблемы?Если бы я писал с нуля, я бы, возможно так и сделал бы, но я пытаюсь перевести уже существующее большое решение, поэтому необходимо минимизировать ручное вмешательство в процесс перевода.
studierenМожно при создании таблицы указывать значения по умолчанию, и туда можно имя пользователя, ну или всё что угодно вписать. Да хоть IP адрес клиента, откуда пришёл запрос. И т.д., и т.п.Основной вопрос, как отобрать из прилинкованного как таблица VIEW только относящиеся к нужной сессии данные. И трудность только в определении на стороне сервере, какой же SessionID нужно сопоставить Connection в котором сам Access запросил данные. И если ничего придумать не удастся, то за SessionID будет принято Имя пользователя, хотя сейчас пользователей нет и не понятно, можно ли их будет завести.
studierenМногие вещи, которые Вы сделали в MS Access в MS SQL Server решается куда более изящно, там есть крутые инструменты.Согласен. Но его неспособность полноценно работать с "динамическим SQL" очень мешает как раз при переходе с Access.
studierenПоэтому слепо копировать решение для Access в MS SQL Server мне кажется не стоит. Надо смотреть на конкретную задачу.Совершенно с вами согласен. Не стоит, но приходится... Эта необходимость и следует из конкретной задачи.

studieren,

Сделано с таблицей сессий. Но для исходного аксесса сессия определяется по имени хоста и полному имени интерфейсной базы. А после перехода на SQL Server получается только по имени хоста. (Или как вы предложили по имени Пользователя/Логина)

Для запускаемых/открываемых из кода используется единый настраиваемый Connection, и внутри него можно настроить вычисление SessionID как в Access.
А как поступить с прилинкованными VIEW и PassTrought запросами? Ведь для них Access использует свой Connection, который ещё(как я прочитал) создаётся и пересоздаётся по случайности и надобности Access.
Можно ли, например, в строке подключения TableDef.Connect указать параметр, доступный на стороне сервера?

studierenВидите ли если юзер сегодня подключается к SQL, то получает одно значение сессии, а когда на следующий день подключается вновь, то получает совсем, совсем другое значение сессии.
Иммено так. Поэтому и используется придуманное разделение на придуманные сессии по имени хоста и имени интерфейсной базы. Но как получать имя интерфейсной базы на стороне сервера - узнать не получается и, видимо придётся, загрубить разделение по сессиям до имени хоста.

studieren,

Имя хоста так-же просто получить как и IP адрес, а использовать имя хоста, на мой взгляд, более правильно.
Название не самой базы на сервере, а имя интерфейсной базы Access, которая открыла прилинкованный View.

studieren,

Даже проще:

А передать ничего нельзя. Только если как нибудь на стороне сервеора получить параметры из строки подключения.

court,
Спасибо большое!

А можно ли на сервере получать дополнительные параметры из ConnectionString?
ODBC;DSN=try;UID=User;PWD=pwd;DATABASE=db; CustomProperty=CustomValue
Или только с "Application Name" можно работать?

Шыфл,

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

Да и HWD хорош для терминального варианта, а не для работы по сети.