Форум: "Базы";
Текущий архив: 2005.03.27;
Скачать: [xml.tar.bz2];
ВнизГлобальные переменные в FireBird Найти похожие ветки
← →
Ярослав (2005-02-21 07:44) [0]Подскажите можно ли объявить глобальную переменную для текущего подключения в базе FireBird. Например имя пользователя, имя приложения, хост и др. чтобы использовать их в триггерах, ХП.
← →
ЮЮ © (2005-02-21 08:27) [1]Он что у тебя один к серверу приконнектился? в теле триггеров, ХП и определяй. Для ХП внутреннего пользования можешь передавать в качестве параметра, если определять лень
← →
Digitman © (2005-02-21 08:28) [2]
> Например имя пользователя
см. CURRENT_USER
> имя приложения
оно у тебя всегда будет одним и тем же - fbserver.exe
> хост и др
зачем в ХП/триггере знать свой или клиентский хост ?
← →
Ярослав (2005-02-21 09:06) [3]1. Если бы он один приконнектился то проблем бы не было.
2. Имя приложения - имеется ввиду имя клиенского приложения
3. В ХП или Триггере все это надо для хранения истории, т.е. кто, когда, и с какой машины создал/изменил запись в таблице.
Current User это хорошо, но пользователи в принципе могут подключаться по одним Login-ом
← →
Johnmen © (2005-02-21 09:09) [4]>но пользователи в принципе могут подключаться по одним Login-ом
Значит это один пользователь с т.з. сервера.
← →
Digitman © (2005-02-21 09:18) [5]
> 2. Имя приложения - имеется ввиду имя клиенского приложения
серверу фиолетово, какое приложение стало его клиентом .. об этом ты должен заботиться сам, например, создав ХП с параметром "AppName" и вызывая его на кл.стороне
> 3. В ХП или Триггере все это надо для хранения истории,
> т.е. кто, когда, и с какой машины создал/изменил запись
> в таблице.
> Current User это хорошо, но пользователи в принципе могут
> подключаться по одним Login-ом
на то на стороне сервера в ХП/триггере есть уникальное значение SESSION_ID .. совместно с CURRENT_USER это дает уникальную идентификацию кл.сессии
← →
Val © (2005-02-21 11:04) [6]т.е., по сути вопроса - глобальные переменные на данном SQL-сервере реализуются с помощью хранимых процедур, возвращающих их(переменные) в виде параметров.
← →
ЮЮ © (2005-02-21 11:19) [7]Val © (21.02.05 11:04) [6]
правильнее: локальная переменная ХР будет "глобальной" для других ХП, вызываемых в теле первой процедуры, которым она передается в качестве параметра.
← →
Val © (2005-02-21 11:36) [8]>ЮЮ © (21.02.05 11:19)
я говорил не об областях видимости, а об имитации глобальных переменных.
← →
DSKalugin © (2005-02-21 11:37) [9]Глобальные переменные определяй в клиентском приложении,
а в базу для всяких там триггеров, ХП и прочего передавай в
качестве параметров
в БД я знаю только одну глобальную переменную USER
проверяется так
SELECT user from rdb$database
← →
ЮЮ © (2005-02-21 11:44) [10]>DSKalugin © (21.02.05 11:37) [9]
>в БД я знаю только одну глобальную переменную USER
и что, ей можно присвоить что-то?
>Val © (21.02.05 11:36) [8]
и как "с помощью хранимых процедур, возвращающих их(переменные) в виде параметров" может "имитировать" глобальную переменную?
← →
Val © (2005-02-21 11:50) [11]>[10] ЮЮ © (21.02.05 11:44)
хп - как метод Set/Get(как угодно) поля/ей собственной таблицы для хранения значений. Некий аналог работы с property.
← →
Digitman © (2005-02-21 11:53) [12]в целом говоря, конечно же можно для этой цели "извратиться" с хранением своих глобальных значений в секции данных UDF .. при этом юзер, дабы "нарисоваться", обязательно должен сразу после коннекта вызвать некую специально разработанную для этой цели UDF
но овчинка выделки не стоит - изврат он и есть изврат .. посему подробности на эту тему считаю приводить бессмысленным
← →
Ярослав (2005-02-21 11:53) [13]> Digitman © (21.02.05 09:18) [5]
> на то на стороне сервера в ХП/триггере есть уникальное
> значение SESSION_ID .. совместно с CURRENT_USER это
> дает уникальную идентификацию кл.сессии
Все что было нужно (если это работает, еще не пробовал)
Создаем таблицу и пишем в нее все что угодно с ключем SESSION_ID
← →
DSKalugin © (2005-02-21 11:59) [14]ЮЮ ©
Че к словм придераешься? Как иначе это назвать?
← →
DSKalugin © (2005-02-21 12:07) [15]Digitman © (21.02.05 11:53) [12]
не не не UDF тут не поможет. Тем более в архитектуре Классик
← →
Digitman © (2005-02-21 12:39) [16]
> DSKalugin © (21.02.05 12:07) [15]
> не не не UDF тут не поможет
не спорь.
при определенных знаниях Win32 и "потрохов" IB-совместимого сервера UDF-механизм с определенными ограничениями можно приспособить и для таких задач
> Тем более в архитектуре Классик
подразумевался СуперСервер
← →
Ярослав (2005-02-22 06:33) [17]Digitman © (21.02.05 09:18) [5]
> на то на стороне сервера в ХП/триггере есть уникальное
> значение SESSION_ID .. совместно с CURRENT_USER это дает
> уникальную идентификацию кл.сессии
А как мне SESSION_ID получить?
← →
Digitman © (2005-02-22 08:09) [18]
> Ярослав (22.02.05 06:33) [17]
если не ошибаюсь, так и получить - SESSION_ID
уточни на ibase.ru
← →
Ярослав (2005-02-24 06:30) [19]Ну не нашел я как получить SESSION_ID. USER нормально вставляется, а SESSION_ID нет. На ibase.ru тоже ни чего не нашел.
Подскажите, кто ни будь, а то очень надо.
← →
Digitman © (2005-02-24 09:30) [20]приношу извинения ... наврал с SESSION_ID .. термин "сессия" и ид-р сессии применим к кл.стороне, а его эквивалент для серв.стороны - CURRENT_CONNECTION
цитирую Еманова (ReleaseNotes.pdf) :
(1.5) New context variables
Dmitry Yemanov
CURRENT_CONNECTION
and
CURRENT_TRANSACTION
Each of these context variables returns the system identifier of the active connection or the current
transaction context, respectively. Return type is INTEGER. Available in DSQL and PSQL. Because
these values are stored on the database header page, they will be reset after a database restore.
Syntax
CURRENT_CONNECTION
CURRENT_TRANSACTION
Examples
SELECT CURRENT_CONNECTION FROM RDB$DATABASE;
NEW.TXN_ID = CURRENT_TRANSACTION;
EXECUTE PROCEDURE P_LOGIN(CURRENT_CONNECTION);
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2005.03.27;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.039 c