Триггеры... А стоит ли использовать...

← →
Rafe (2003-12-07 17:14) [0]

Всем привет! Никогда не использовал триггеры. Обходился ХП. Есть такая задача: при изменении значения в поле одной таблицы изменять значение (по определенному правилу) в другом поле этой же записи этой же таблицы. По аналогии вычисляемых полей. Стоит ли для этого использовать триггеры. Объясню на простом примере:

Tab1
---------------
Fld1 Fld2

И надо на изменение (UPDATE) значения в поле Fld1 изменить значение, например в поле Fld2 = 3*Fld1.

Стоит ли использовать Триггеры или нет?
Если у кого есть опыт в написании триггеров, просьба, если не сложно, написать его на основе данного примера.

← →
Shirson (2003-12-08 05:55) [1]

А как это делать БЕЗ триггеров? Ручками отслеживать? :) В сад.
Триггеры для этого и существуют, чтобы голова не болела.

Делаешь триггер на INSERT и вычисляешь поле

set nocount on update Tab1 set Fld1=Fld2*3

← →
Shirson (2003-12-08 08:24) [2]

блин, поля переставил :(

set nocount on update Tab1 set Fld2=Fld1*3 where id in (select max(id) from inserted)

← →
Ega23 (2003-12-08 09:01) [3]

С одной стороны, триггеры для этого и предназначены.
Но, на мой взгляд, удобнее обходиться sp-хой. Ведь на клиенте большой разницы нет:
написать Insert into Tab1 (Fld1) Values (1)или Exec sp_MySP @mode=1, @Value1=1
Но если ошибха в sp-хе, то её перенакатить элементарно, а вот с триггером все не так просто.

← →
Shirson (2003-12-08 09:27) [4]

Оригинально...
И что с нем не так просто? Или, вопрос с другого ракурса - чем триггер отличается от sp?

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

Если это делается отдельной sp, то найдётся ситуация, когда кто-то (по злому умыслу, по забывчивости или еще дюжине причин), долбанёт туда insert. И целостность поплыла в далёкие края. Т.е. достоверность таблицы, за реакцию на модификацию которой отвечает КЛИЕНТ, стремится к 0.

← →
Ega23 (2003-12-08 10:21) [5]

> Оригинально...
> И что с нем не так просто? Или, вопрос с другого ракурса
> - чем триггер отличается от sp?

Скажем так: для конечного клиента, если грамотно настроен сервер - SP может всегда заменить триггер, а вот наооборот - не всегда.

← →
Fay (2003-12-08 10:23) [6]

>> если грамотно настроен сервер - SP может всегда заменить
>> триггер
Бред

← →
Danilka (2003-12-08 10:27) [7]

[5] Ega23 (08.12.03 10:21)
между прочим, триггер служит совсем не для того, чтобы заменять ХП.
а ХП ну никак не заменит триггер, даже при самом грамотно настроенном сервере в мире, если я сделаю инсерт напрямую в таблицу. :))

← →
Shirson (2003-12-08 10:28) [8]

Триггер, это sp, которая запускается при модификации таблицы, и "входным параметром" является таблица модификации (inserted или deleted) - то, что было удалено/вставленно из/в таблицу, на которой висит триггер.

Обеспечивать реакцию базы на изменения в таблице простыми sp - шаг назад. И неважно, как настроен сервер. Как бы грамотно его не настраивали, если на таблице нет триггера, значит эту таблицу можно модифицировать и база об этом не узнает. Поэтому sp не заменит триггера. Иначе бы никто не придумывал триггеры.

← →
Ega23 (2003-12-08 10:43) [9]

> Danilka ©

> Shirson ©

Все верно. Все вы правильно пишите. Но:

> если я сделаю инсерт напрямую в таблицу.

О каком грамотно настроенном сервере (и клиенте) тогда идет речь, если он может напрямую сделать инсерт в таблицу?

> Обеспечивать реакцию базы на изменения в таблице простыми
> sp - шаг назад. И неважно, как настроен сервер. Как бы грамотно
> его не настраивали, если на таблице нет триггера, значит
> эту таблицу можно модифицировать и база об этом не узнает.
> Поэтому sp не заменит триггера. Иначе бы никто не придумывал
> триггеры.

Ситуация: есть таблицы персонала, пропусков, расписаний доступа и т.д., всего около 50-ти штук. Практически каждое изменение во всех этих таблицах произведенное оператором должно отражаться в таблице протокола. Вопрос: как тогда в триггер передать код оператора и код рабочей станции?
Так что я ничего не имею против триггеров, но сам их использовал раза 2 всего. Правда, в той ситуации действительно не помогла бы никакая SP.

← →
Danilka (2003-12-08 11:55) [10]

[9] Ega23 (08.12.03 10:43)

> О каком грамотно настроенном сервере (и клиенте) тогда
> идет речь, если он может напрямую сделать инсерт в таблицу?

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

> Ситуация: есть таблицы персонала, пропусков, расписаний
> доступа и т.д., всего около 50-ти штук. Практически каждое
> изменение во всех этих таблицах произведенное оператором
> должно отражаться в таблице протокола. Вопрос: как тогда
> в триггер передать код оператора и код рабочей станции?

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

← →
Desdechado (2003-12-08 12:11) [11]

а по 1-му вопросу - почему бы и в самом деле вычисляемое поле не использовать?

← →
Silver Alex (2003-12-08 12:14) [12]

согласен с Ega23 в данной ситуации все просто, можно обойтись и триггером.Но бывает ситуация когда действительно легче обойтись SP.Ну а если что-либо делать "по злому умыслу, по забывчивости ..", то никакой триггер не спасет

← →
Ega23 (2003-12-08 12:15) [13]

> ну-ну. пишу скрипт на жаба-скрипте - 4 строки, который инсертит
> напрямую в таблицу. записываю его в файл с расширением js.
> запускаю. и весь твой мегаправильный сервер лажается по
> самое нехочу. а клиент вообще отдыхает, ибо не трогали его.
> конечно, надуманный пример, но все равно, ты глубоко заблуждаешься,
> если считаешь, что за всю историю жизни этой БД, с которой
> сейчас ты работаешь, ты будешь единственным разработчиком.
> :))

Ну это мы пришли к безопасности сервера. Конечно, взломать можно всё. Но если у тебя NT-шные права в сети - обычный user, если физически вынут CD-ROM, если серверная закрыта от тебя на 3 замка, если ты понятия не имеешь, под каким Login"ом ты к серверу коннектишься, то взломать его оччень непросто.
А разработчику даже иногда (не всегда, но иногда) полезно бывает, чтобы "следов не осталось" :-)

> ну конечно, протокол надо писать триггерами, а вот как узнать
> код оператора и код рабочей станции зависит от структуры
> твоей БД, правда, в протокол обычно пишется логин и текущее
> дата/время, как правило, этого достаточно для любых разборок.

Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName (имя рабочей станции). По этим параметрам определяется ID рабочей станции, ID оператора, его права и т.д.
Таблица протокола как раз и состоит из : Текущее время, ID оператора, ID раб. станции и ID действия, которое он делал (например - добавление нового сотрудника). Ну и плюс всякие примечания.
Так вставку в протокол через триггер не сделаешь. Или в таблицу персонала надо ещё 2 поля добавить: Код оператора и Код раб. станции.

← →
Shirson (2003-12-08 12:21) [14]

>Ну это мы пришли к безопасности сервера. Конечно, взломать можно всё. Но если у тебя NT-шные права в сети - обычный user, если физически вынут CD-ROM, если серверная закрыта от тебя на 3 замка, если ты понятия не имеешь, под каким Login"ом ты к серверу коннектишься, то взломать его оччень непросто.

>Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName (имя рабочей станции).

Мде... а броадкаст не пробовали в сеть делать? С этим паролем? :)
Или в FAR на программе F3 нажать и посмотреть, какой пароль заносится в sp? :)

← →
Ega23 (2003-12-08 12:21) [15]

> Silver Alex ©

Полностью согласен.

← →
Ega23 (2003-12-08 12:27) [16]

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

← →
SergSuper (2003-12-08 13:03) [17]

Из клиентской программы при старте запускается sp с параметрами: Логин (личный логин оператора для системы, не для NT), Пароль, PCName ().

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

← →
Ega23 (2003-12-08 13:17) [18]

> SergSuper (08.12.03 13:03) [17]

Сначала дам СВОЕ определение: MyКСС - МОЯ клиент-серверная система, т.е клиентская программа + СУБД (MSSQL 7.0)+ сама база.

Операторов может быть хоть 1000. И что, каждому отдельно на сервере БД заводить логин и права прописывать?
Каждый оператор из клиентской программы коннектится к серверу под одним и тем-же аккаунтом (которого он не знает). Параметры этого коннекта в экзешнике программы намертво прошиты, это константы. А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться, чтобы получить набор разрешённых действий на клиенте, и чтобы оставить след в протоколе.

← →
Shirson (2003-12-08 13:19) [19]

>Пароль не на сервер, не на NT, этот пароль, под каким юзер в самой базе числиться

Вот про то и речь. Берём этот пароль и лезем в базу в обход её навороченности.

← →
Ega23 (2003-12-08 13:25) [20]

> Вот про то и речь. Берём этот пароль и лезем в базу в обход
> её навороченности.

куда ты с ним полезешь? Это не есть аккаунт. Для сервера это ничто. Эта вещь имеет смысл только для клиентской программы. И ВСЕ.

← →
Danilka (2003-12-08 13:29) [21]

> Операторов может быть хоть 1000. И что, каждому отдельно
> на сервере БД заводить логин и права прописывать?

Неужели это так сложно?

> А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться,
> чтобы получить набор разрешённых действий на клиенте, и
> чтобы оставить след в протоколе.

Все-таки непонимаю, зачем все это? Значит, в самой программе зарегистрироваться - без проблем, а еще одного юзера на сервере завести - проблема? Зачем изобретать велосипед, делать то, что уже давно сделано, то что делается элементарно штатными средствами?

← →
Ega23 (2003-12-08 13:46) [22]

> Вот про то и речь. Берём этот пароль и лезем в базу в обход
> её навороченности.

А вот чтоб такого и не было.

← →
Danilka (2003-12-08 13:52) [23]

[22] Ega23 (08.12.03 13:46)
с учетом того, что логин с паролем зашиты в экзешнике, то узнать их - не проблема.

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

← →
Ega23 (2003-12-08 14:05) [24]

Да знаю я эту политику безопасности.
Проблема гораздо более приземленная - где ты найдешь толкового сисадмина, который пойдет на штатную должность в бюджетном предприятии. максимум на что он там может рассчитывать - 10 штук. Так что это проблема кадров. Нужно сделать так, чтоб юзера вообще Enterprise Manager запустить не могли. И в master с msdb сами ручками лазить не могли. Им вообще не надо знать, что это такое.

← →
SergSuper (2003-12-08 14:18) [25]

>Ega23 (08.12.03 13:17) [18]

Операторов может быть хоть 1000. И что, каждому отдельно на сервере БД заводить логин и права прописывать?
Согласитесь что это в любом случае надо где-то прописывать и если Вы считаете что доморощенные средства лучше стандартных, то почему бы Вам и сервер свой не написать?

Каждый оператор из клиентской программы коннектится к серверу под одним и тем-же аккаунтом (которого он не знает). Параметры этого коннекта в экзешнике программы намертво прошиты, это константы. А вот в самой MyКСС (см. выше) оператор должен зарегистрироваться, чтобы получить набор разрешённых действий на клиенте, и чтобы оставить след в протоколе.
Ну вобще-то плакать хочется читая такое. Я еще понимаю когда это делается в трёхзвенной архитектуре или чтобы уменьшить количество коннектов для экономии на лицензиях. Но вместо того чтобы грамотно раздать права городить свою систему паролей...

← →
Silver Alex (2003-12-08 14:19) [26]

теперь уже тут обсуждают безопасность? :))
Опять соглашусь с Ega23.Можно конечно для 1000 операторов завести логины в самой базе, и на уровне базы раздать права. Но это в стандартной ситуации где добавление, изменение , удаление. А нам нужны права допустим на сверку документа, вот тут метод Ega23 как раз подходит(сам так делаю) .Опять же если дать продвинутому пользователю логин и пароль к серверу значит он может туда залезть в обход клиентской программы, а это уже чревато последствиями

← →
Ega23 (2003-12-08 14:29) [27]

Во!
Наконец-то хоть кто-то понял, зачем вся эта байда с собственными паролями была нужна. просто это тяжело вот так в письменном виде и кратко объяснить.

← →
Shirson (2003-12-08 14:29) [28]

Если прога имеет возможность выполнять операции на сервере, значит она имеет серверный логин и серверный пароль.
Если она их имеет, они могут быть из неё извлечены. На 99% уверен, что они там хранятся "на виду".
Отсюда вся эта навороченная безопастность получается опастностью.

(Я сталкивался с такой проблемой, когда юзер должен работать с базой, но не должен иметь к ней доступа. Тоже приходил к подобному решению - но отказался от него, потому как шило меняем на мыло. Если нужна безопасность, то такая система колется на ура. Если безопасность не особо нужна, то и огород городить незачем.)

← →
Ega23 (2003-12-08 14:39) [29]

> Shirson © (08.12.03 14:29) [28]

Делаем следующее:
Создаем в базе таблицу из одной записи - зашифрованного логина и пассворда. Юзер коннектится из экзешника именно к этой таблице, т.к. по тому логину с пассвордом ты получаешь доступ к базе только на чтение этой самой одной-единственной таблицы.
Далее, получив из базы уже реальный аккаунт, делаем реконнект.
Теперь полные права на базу.

← →
MOA (2003-12-08 14:51) [30]

А чем не подходят роли базы и группы Windows? - Ведь если их использовать, юзеров в базе и на сервере не нужно прописывать вообще. А роли в том или ином виде - "самопальном" или готовом - делать всё равно ведь придётся.
По вопросу - я бы не стал хранить в базе вычисляемые поля, если это не "вспомогальная" таблица (которая удалится стразу после создания), поскольку нарушение основной идеи "каждое значение ровно в одном месте". Зачем хранить то, что вычисляется?

← →
Danilka (2003-12-08 14:57) [31]

[29] Ega23 (08.12.03 14:39)
вобщем-то я не большой спец по МС-Скулю, но, если ты ломишся ни сервер через ОДБЦ, то можно сделать так:
заходишь в администратор источников данных ОДБЦ, запускаешь трассировку, запускаешь свою программу, смотришь лог, того что она делала, из которого видишь, что она заломилась с одним паролем, прочитала данные из такой-то таблицы, перелогинилась, а дальше сам повторяешь ее действия откуда угодно.
ну, а имея реальные логины с паролями и не имея никаких ограничений со стороны сервера делаешь что душе угодно. :)

> [30] MOA © (08.12.03 14:51)
> А чем не подходят роли базы и группы Windows

они и подходят, в самый раз.

← →
SergSuper (2003-12-08 14:58) [32]

Опять соглашусь с Ega23.Можно конечно для 1000 операторов завести логины в самой базе, и на уровне базы раздать права. Но это в стандартной ситуации где добавление, изменение , удаление. А нам нужны права допустим на сверку документа, вот тут метод Ega23 как раз подходит(сам так делаю) .

Написать процедуру сверки и раздавать на неё права, а на сами таблицы права не давать. Или только на чтение. Какие проблемы то?

Если возвращаться к исходной теме - для чего надо использовать триггеры.
Например у меня есть таблица проводок(это для бухгалтерии). Вставка/удаление проводки изменяет остатки на соответствующих счетах. У меня на проводки стоит триггер и откуда бы я проводки не вставлял - я не беспокоюсь об остатках. И удалять могу проводки не процедурой, а delete-ом по условию. При этом доступ к остаткам есть только на чтение. Ну и заодно протоколирование обеспечивается. Мне кажется для таких случаем процедура была бы не так удобна.

← →
Silver Alex (2003-12-08 15:21) [33]

> SergSuper (08.12.03 14:58) [32]

> Написать процедуру сверки и раздавать на неё права, а на
> сами таблицы права не давать. Или только на чтение. Какие
> проблемы то?

Конечно, на сверку можно так.Но откуда вычитать права на печать (или еще что-либо по фантазии заказчика).Ну вобщем бывают случаи, как ни крути

← →
Ega23 (2003-12-08 15:24) [34]

> А чем не подходят роли базы и группы Windows? - Ведь если
> их использовать, юзеров в базе и на сервере не нужно прописывать
> вообще. А роли в том или ином виде - "самопальном" или готовом
> - делать всё равно ведь придётся.
> По вопросу - я бы не стал хранить в базе вычисляемые поля,
> если это не "вспомогальная" таблица (которая удалится стразу
> после создания), поскольку нарушение основной идеи "каждое
> значение ровно в одном месте". Зачем хранить то, что вычисляется?

Совершенно необязательно, что доменный администратор будет вообще иметь доступ к этой базе. И наоборот, пользователь домена с юзеровскими правами может иметь полный доступ к серверу. Это разграничение прав администратора NT и администратора БД.

← →
Ega23 (2003-12-08 15:28) [35]

> Конечно, на сверку можно так.Но откуда вычитать права на
> печать (или еще что-либо по фантазии заказчика).Ну вобщем
> бывают случаи, как ни крути

ВО! Это и есть именно такой случай. Более того, такой "экзотики" там - пруд пруди. Печатать отчеты, назначать расписания на магнитную карту, фотографировать сотрудника и т.д. и т.п.

← →
MOA (2003-12-08 15:43) [36]

>Совершенно необязательно, что доменный администратор будет вообще иметь доступ к этой базе
И на здоровье! Действуем так:
Тщательно анализируем роли, которые будут иметь место в нашей базе (на этапе постановки задачи. Корректируем "по ходу"). Раздаём права ролям.
Тщательно разбиваем юзеров на группы Windows - согласно их роли в организации. Мы подсказываем админу сети, какие группы нам могут понадобится, если админу БД это нужно.
Затем админ БД помещает нужные группы в роли базы. Если есть небольшие отклонения (ну, например, данную роль имеет только один юзер) - админ базы вводит в роль именно этого одного пользователя.
Дело-то в том, что эту работу всё равно придётся делать, но возникают большие сомнения в недырявости "самопального" решения + расходы на разработку такого решения.

← →
Shirson (2003-12-08 15:52) [37]

>Ega23 (08.12.03 14:39) [29]
Делаем следующее:
Создаем в базе таблицу из одной записи - зашифрованного логина и пассворда. Юзер коннектится из экзешника именно к этой таблице, т.к. по тому логину с пассвордом ты получаешь доступ к базе только на чтение этой самой одной-единственной таблицы.
Далее, получив из базы уже реальный аккаунт, делаем реконнект.
Теперь полные права на базу.

Вариант получше, но всё равно не то. Пароль расшифровывается на клиенте и через него-же идёт коннект к базе. Значит всё, что нужно для расшифровки есть в клиенте.

Ладно, это дебри безопастности и не о том речь.

Триггеры и sp гармонично друг друга дополняют и прекрасно работают вместе, не вытесняя друг друга. Только на триггерах или только на sp сделать хорошую вещь - вряд ли.

← →
Ega23 (2003-12-08 16:00) [38]

OperCod OperName
------- --------------------------------------------------------
0 Доступ к модулю БЮРО ПРОПУСКОВ
1 Завершение работы с модулем БЮРО ПРОПУСКОВ
2 Аудит БЮРО ПРОПУСКОВ
10 Работа с персоналом
11 Добавление сотрудника
12 Изменение данных сотрудника
13 Удаление данных сотрудника
14 Печать учетной карточки
15 Изменение пин-кода
30 Работа с пропусками
31 Добавление нового пропуска в БД
32 Изменение данных пропуска
33 Удаление пропуска из БД
34 Поиск по пропуску
35 Выдача нового пропуска сотруднику
36 Изъятие пропуска у сотрудника
40 Работа с планом доступа
41 Назначить план доступа
42 Изменить план доступа
43 Удалить доступ
44 Сверка назначений
45 Диспетчер назначений
50 Специальные функции
51 Изменение периода доступа сотрудника
52 Назначение группового разового доступа
53 Добавление назначений по образцу
54 Экспорт активной таблицы
61 Фотографирование сотрудника
62 Печать пропуска
63 Взвешивание сотрудника
64 Удаление фотографии
65 Неудачная печать пропуска
66 Печать неидентифицир. пропуска
80 Доступ к протоколу
81 Очистка протокола
100 Доступ к настройкам системы
101 Просмотр списка пользователей
102 Модификация данных пользователя
103 Просмотр списка организаций и подразд.
104 Модификация данных об подразделениях
105 Просмотр списка должностей
106 Модификация данных о должностях
107 Просмотр списка рабочих станций
108 Модификация данных о рабочей станции
109 Просмотр списка АРМ
110 Модификация конфигурации АРМ
111 Просмотр списка типов пропусков
112 Просмотр списка статусов пропусков
113 Просмотр списка производителей пропусков
114 Просмотр списка доп.признаков пропусков
115 Модификация списка доп.признаков пропусков
116 Модификация данных об организации
117 Просмотр параметров
118 Модификация параметров
119 Модификация конфигурации АРМ
120 Модификация конфигурации устройств
121 Просмотр временных окон
122 Модификация временных окон
123 Просмотр расписаний доступа
124 Модификация расписаний доступа
125 Просмотр типов дней
126 Модификация типов дней
127 Просмотр планов доступа по дням
128 Модификация планов доступа по дням
129 Просмотр календаря
130 Модификация календаря
131 Генерация календаря
132 Просмотр групповых планов доступа
133 Модификация групповых планов доступа
134 Просмотр списка праздничных дней
135 Модификация праздничных дней
136 Просмотр графиков
137 Модификация графиков
500 Доступ к оперативным сводным
501 Просмотр списка сотрудников
502 Просмотр сводной по сотруднику
503 Просмотр табелей сотрудников
504 Просмотр сводной посещений по гостевым пропускам
505 Просмотр сводной по конфигурации АРМ
506 Просмотр сводной по выданным гостевым пропускам
507 Просмотр сводной по системе
508 Просмотр сводной по расписанию
509 Просмотр сводной по перемещениям
998 Системная операция
999 Неизвестная операция
0 Доступ к отчетно-аналитической системе
1000 Персонал и пропуска
1010 Список сотрудников
1020 Выданные гостевые пропуска
2000 Перемещения
2020 Проходы через ТД
2030 Пребывание в зоне
3000 Система
31000 Специальные
31510 Импорт из CardBase
31520 Экспорт в CardBase

(97 row(s) affected)

Все эти 97 операций должны отслеживаться на клиенте: страничку у PageControl не переключить, если нельзя; кнопку Disable сделать, если операция запрещена и т.д.
Список этих операций постоянно растет. И что проще: изменить пару SP и exe-шник и переслать клиенту по почте, либо ехать на объект и добавлять операции во все роли и перераздавать права на процедуры с таблицами?
А если на объекте заболел тот товарищ, который пропуска печатает? Тогда временно другому пользователю системы дают эти права непосредственно из пользовательского интерфейса, а потом, когда надо, их отбирают.
Таким образом заказчик получает возможность самому распределять роли между операторами, при этом совершенно не зная о том, что есть какой-то Enterprize Manager и Query Analyzer.

← →
Danilka (2003-12-08 16:12) [39]

> [38] Ega23 (08.12.03 16:00)

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

← →
Ega23 (2003-12-08 16:16) [40]

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

А вот эта мысль мне что-то в голову не приходила. За идею - спасибо.
Но как быть с правами доступа к sp и таблицам? Если их временно надо поменять?

Триггеры... А стоит ли использовать... Найти похожие ветки