В чем проблема? Для вызова sp_setapprole необходим пароль, который и необходимо защитить от Пользователя.
Рекомендуют (Richard Waymire) хранить его в реестре, запретив доступ к ветке всем, кроме Приложения.

Вы можете запретить доступ к Вашей таблице (только через SP), если вы там храните пароль...

Удачи

Например так:

Создается сервис MyApp, запускается под учетной записью
MyAccount. Доступ к ветке реестра запрещается всем, кроме MyAccount.

Удачи

Речь идет о приложении, которое должно работать везде (на всех версиях Win)

Простите, я что-то такого условия не вижу.

Более того, устанавливать SQL Server на не серверную
платформу (т.е. на 9x или NT Workstation/2000 Professional/XP) для production систем, мягко говоря, неправильно.

Позволю себе еще высказаться по поводу подхода "зашифровать пароль при помощи ключа, известного только приложению и сохранить в реестре".
Пользователь может изучить работу приложения и извлечь ключ... Может точку останова поставить...

Уважаемый г-н Jimmy.

Касательно проблемы г-жы anna510: можно вызывать sp_setapprole внутри процедуры, проверяющей пароль и, таким образом, не дать Пользователю увидеть пароль AppRole. Об этом я и написал в своем первом ответе. Это обеспечение безопасности хранения пароля средствами SQL Server'a, что есть полный аналог предложенному мной способу с сервисом. Недостаток его -низкое качество кода SQL Server'a в смысле безопасности по отношению к аналогичному коду ОС (что естественно), так что я более доверяю механизмам ОС.

Я привел пример наиболее грамотного, на мой взгляд, решения по защите пароля AppRole. Безусловно, г-же anna510 он не подходит, т.к. приложение уже написано.

Кроме того, решение с сервисом вовсе не требует работы на сервере - клиентское приложение с любой машины соединяется с сервером, где наш сервис и слушает. Он обеспечивает хранение пароля и соединение с SQL Server'ом. Вот и все.

Если пользователь знает пароль AppRole, то он сможет ее активировать, как Вы понимаете...

Удачи