1024

---------
это неправильно. Таким образом ты отказываешся от предоставляемых сервером
средств по разделению прав доступа и пытаешся создать их сам.
1.Лишняя работа,
2.лучше чем в скл сервере сделать практически невозможно,
3.могут быть ошибки в твоём коде.
4.Кроме того если права на доступ к данным прописаны на сервере то никакой
пользователь никакими средствами не сможет ни посмотреть ни изменить то что
ему не разрешено, вопросы с аксесом/екселом просто не возникают

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

Не согласен, что это не правильно.
Средства управления доступом в SQL Server (логины, пользователи, роли, разрешения) плохо согласуются с бизнес логикой приложения. Согласитесь, что гораздо проще и правильней не дать возможность пользователю делать то, что ему не положено, а не получать с сервера ошибку типа denied access. Сервер дает возможность управлять правами на уровне ОБЪЕКТОВ сервера (таблица, колонка, процедура ии пр.), а в приложении права даются на уровне бизнес объектов приложения (документов, справочников, отчетов и пр.). Связать их очень не просто, значительно проще все это сделать через приложение. Например так http://www.caws.atnet.ru/vfox/sql6.html.
И не надо упорствовать :)
С уважением, Алексей.

novaКак назначить разрешения для роли на все объекты базы данных?
1. Через код: команда T-SQL GRANT. Посмотрите в BOL ее синтаксис. В зависимости от объекта, синтаксис разный.
2. Через EM. Находите требуемую роль, двойным щелчком на ней и кнопка Permissions.
С уважением, Алексей.

1024возникают вероятно от незнания/недостаточного опыта по работе с скл серверами и самим скл. Нормально там всё с согласованием бизнес логики и управлением доступом.
Насчет моего опыта с SQL ... Давайте не переходить на личности... Я работаю с SQL, начиная с верисии 6.0 и читаю ВСЕ курсы по SQL (2071, 2072, ....2093) в одном из Московских учебных центров Microsoft ...Лучше подтвердите свои высказывения примерами. На вашей страницы я не нашел НИЧЕГО, относящегося к вопросу темы. Что ТАМ "всё с согласованием бизнес логики и управлением доступом."? (ваша цитата). И где там? Если вы про SQL Server, то там ничего не согласовано с бизнес логикой. Приведите пример, что имеется в виду.
Каким образом, например, администратор программного комплекса (не SQL Server) может управлять доступом к бизнес - обьектам средствами самого SQL Server? Он что должен запускать EM или QA?
Как правило, одному бизнес-объекту в системе соответствует несколько объектов базы данных (таблицы, храним. процедуры и пр.). Кто будет решать ДИНАМИЧЕСКИ к камим объектам давать доступ при требовании доступа конкретному пользователю к, например, материальному отчету? Администратор базы данных слов таким просто не знает - "материальный отчет", а администратора системы не представляет какие объекты базы данных отвечают за данный бизнес-объект. Это знает только разработчик. И через клиентское приложение свои знания может реализовать в виде, например, такой формы VFP. Слева выделены пользователи системы, а слева - их права на бизнес-объекты системы.
Еще одно. Вы что-же будут давать права db_onwer или, даже sysadmin администратору базнес-логики ? А не страшно ?
Далее... Вы вообще представляет, сколько может быть объектов базы данных в реальной большой системе? У нас в системе их несколько тысяч. И кто будет разбираться с правами на эти объекты?
Буду ждать вашего ответа на эти вопросы.
С уважением, Алексей.

Вот форма VFP для управления доступа к объектам бизнес - логики.
А вы предлагаете что ? Запускать администратору бизнес-логики EM и проставлять права на таблицы, хранимые процедуры и пр.? Для большой системы это не пройдет.
С уважением, Алексей