У меня есть две схемы, как это:

Схема 'data' -> содержит таблицы, и никто не имеет к ним доступа извнеСхема 'ui' -> содержит представления, которые доступны снаружи; идея заключается в том, что вы можете выбрать / удалить / обновить / вставить в этих представлениях. Таким образом, я делаювладение цепочкой.

Например:

create table data.tblTest (TestKey int not null primary key);
create view ui.vwTest as select * from data.tblTest;

Теперь, если я подключаюсь как пользователь с SQL Studio, все в порядке:

select * from ui.vwTest; -- WORKS (this is correct)
select * from data.tblTest; -- ERROR (this is correct)

insert into   ui.vwTest  (TestKey) values (17); -- WORKS (this is correct)
insert into data.tblTest (TestKey) values (17); -- ERROR (this is correct)

Однако, если я напишу программу на .NET / C #, которая использует SqlCommandBuilder:

SqlDataAdapter ada = new SqlDataAdapter('select * from ui.vwTest', conn);
SqlCommandBuilder b = new SqlCommandBuilder(mSQLAda);
ada.UpdateCommand = b.GetUpdateCommand();
ada.InsertCommand = b.GetInsertCommand();
ada.DeleteCommand = b.GetDeleteCommand();

==> Затем в следующемВСТАВКА НЕ РАБОТАЕТ!

[РЕДАКТИРОВАТЬ]:

SqlCommandBuilder анализирует представление, а не создает команду типа

INSERT INTO ui.vwTest ...

это создает

INSERT INTO data.tblTest ...

Таким образом, фактически SqlCommandBuilder пытается быть «интеллектуальным» и получает доступ к базовым таблицам представления вместо доступа к представлению.

Вопрос: можно ли изменить это поведение?

Кстати, просто чтобы было понятнее, я делаюцепочка владения Вот.

Мои пользователи имеют право видеть представления в схемещ, но у них нет прав на схемуданные, Однако из-за изменения владельца пользователи могут обращаться к таблицам косвенно через представления в схеме.данные.

Подробно пользователь прикреплен к пользовательской роли, например "role_user", а роль имеет права на схему следующим образом:

GRANT SELECT, UPDATE, INSERT, DELETE ON SCHEMA ui TO role_user ;

но роль не имеет ПРАВ на схему данных!

Приятной особенностью этой настройки является то, что вы можете применять защиту на уровне строк. С помощью фильтра where в представлении вы можете выбирать только те записи, которые пользователь может видеть.

Как уже говорилось, он прекрасно работает в окне SQL, но не с SQLCommandBuilder. SQLCommandBuilder анализирует представление и пытается напрямую получить доступ к базовым таблицам, а не к представлению.

7 лет назад кто-то спросил это:https://stackoverflow.com/a/320684/2504785 И тогда он решил сам написать команды SQL. Но, возможно, существует ли сейчас другое решение? Тем не менее, я не нашел ничего до сих пор ...

[/РЕДАКТИРОВАТЬ]