Говорят лучше в таблице хранить
такакакак там надёжнее.
А доставать быстрее из переменной........
Так как же ответить на твой (ВАШ) вопрос.
Храните в таблице и присваивайте значение переменной при первом удобном случае, а потом пусть отваливаются до новой авторизации.........

http://www.hiprog.com/forum/read.php?id_forum=1&id_theme=4071&page=3

Читайте последний топик автора Кабан.

>Сначала я права раздавала через переменные.

Это называется "штаны через голову надевать".

>Какой способ разрдачи прав лучше реализовать в ADP?

Единственно правильный. Создать на SQL-сервере юзеров и назначить им доступ к базам, таблицам и запросам.

Как я думаю, налицо непонимание Вами самой идеологии "клиент-сервер".

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

В архитектуре "клиент-сервер" всю безопасность обеспечивает сервер. Клиент априори считается способным на совершение любых несанкционированных действий. Он может попытаться подключиться к любой базе, считать или записать данные в таблице, выполнить запрос. Задача сервера - разрешить, либо запретить ему эти действия.

Если Вы переходите с mdb на SQL Вам придется в сильно изменить свое понимание организации защиты БД.
Забудьте все извращения с формами, права в таблицах, и что там ещё изобретала Ваша пытливая мысль. В SQL-е это все организуется совершенно по другому - ПРАВИЛЬНО и ПО ВЗРОСЛОМУ.
Файл adp вообще не нужно защищать. НИКАК. В нём только формы и отчёты. Если пытливый юзер его испортил, пусть достает резервную копию из архива и работает дальше как ни в чём не бывало. Вся защита должна быть реализована на сервере.
Как?

Ну во первых, в MS SQL доступ можно определить куда гибче, чем в mdb. К таблицам, например, раздельно назначаются права на чтение, изменение, вставку и удаление записей. Но одними только запретами задачи безопасности решить не удаётся. Как правило, безопасность упирается в дилемму, что нужно разрешить юзеру изменять данные, но при этом обеспечить их корректность. Для этого в MS SQL есть одна ВЕСЧЬ, называемая "хранимые процедуры". Это разновидность запросов SQL-я. В хранимых процедурах не просто исполняются SQL-запросы. Здесь запросы можно помещать в процедурные конструкции, называемые "транзакт-SQL". Т.е. хранимая процедура может проверить переданные ей данные на соответствие каким-то условиям и выполнить, либо нет SQL-запрос.
Таким образом не надо разрешать юзеру запись в таблицу, и потом волноваться насчет того, что он залезет туда в обход формы и все испортит. Запись в таблицу надо запретить. А разрешить ему запуск хранимой процедуры, которая производит эту запись. Пусть юзер ломает форму, или пишет своё приложение - неважно. Сделать он сможет только то, что ему разрешит сервер.
И т. д. и т. п. На MS SQL ещё всякие штучки имеются. Триггеры, например.
Ну, тут Вам и умные книжки в руки...

>>Какой способ разрдачи прав лучше реализовать в ADP?
>
>Единственно правильный. Создать на SQL-сервере юзеров и
>назначить им доступ к базам, таблицам и запросам.
>

Вот здесь Вы меня не поняли. Права на сервере - это понятно. Без них все равно никуда не денешься. Никто и не получит доступа к БД, если ему не дать прав.
Я имею ввиду права на пользование элементами в проекте ADP.
То, что мой проект изначально неправильно сделан под SQL - это я Вас уже поняла. Но пока я не изменила свой проект, не изучила и не создала эти хранимые процедуры, триггеры и другие крутые финтиклюшки (на что у меня уйдет пару-тройку месяцев, так как это не основной род деятельности для меня, а просто мой интерес), то мне придется пользовать своей системой разграничения прав на элементы в проекте ADP.