SQL Server 2005 - Modifying Data through a view - sql

I want users to SELECT and Modify Data trough a view, but give no permissions to the base table.
SELECTing Data trough a View works fine.
But when I want to INSERT, UPDATE or DELETE data through a view, SQL Server says that there are missing permissions on the base table.
Following objects:
Table, named: dbo.test
View, named: dbo.vw_test
The table has two columns:
Column_1 IDENTITY....
Column_2 int (updateable column)
The view has following statement:
SELECT * FROM dbo.test;
I have created a LOGIN and a USER on this database with SELECT, INSERT, UPDATE, DELETE permissions on this view. There is no DENY on the base table.
As said, SELECT works, but updating Column_2 not.
Why? Do I need to grant all rights to the base table?
I hopefully think not. I already have created an INSTEAD OF INSERT trigger on the view to test it. But it doesn't work.
What can I do, to modify data trough a view?

I guess that you've misunderstood views. If you are modifying data inside a view it means that you are directly accessing all tables that exist into the SQL statement defining that View. This means that if you want to modify data, modifications will be done directly to all tables that are represented by that view, which at the end means that you have to give enough permissions in order to be able to perform those kind of actions. Please see the reference in this link (section Before you begin -> permissions).

Related

Transfer data to a newly created view from a table in another database in ssms

I have two different databases. Let's say 'DbOne' and 'DbTwo'.
Is there any way to do the followings?
Create a view in DbOne
Transfer data in a particular table from DbTwo to the newly created view in DbOne.
I am using SSMS and still figuring out the appropriate query..
Please give me any advice.
You need INSERT / SELECT statement - eg.
INSERT INTO DbOne..NewView
SELECT * FROM DbTwo..SourceTable
However, depending on the structure of both tables, you may need to specify the particular columns in the SELECT statement, to match the structure of the target table. (By the way, note that data is always going into a TABLE - not a VIEW. You can do an INSERT into a VIEW, but only under certain conditions)

Azure / Transact SQL: Dynamically create View of tables with the same name OR add tables after View creation

I'm new to Azure and not great with SQL so any help would be greatly appreciated.
I have a Database where each user has a Schema. Each Schema has identically structured tables with the same name, say "Table".
I now require a View in another Schema which provides a read-only union of all the rows from all the tables Table.
I was successful in creating a Schema, say Views, handling its permissions and creating a View, "TableView", with the following SQL from Partitioned Views # learn.microsoft.com:
CREATE VIEW Views.TableView
AS
SELECT *
FROM Schema1.Table
UNION ALL
SELECT *
FROM Schema2.Table
UNION ALL
SELECT *
FROM Schema3.Table
...
GO
I now wish for this View to be dynamic as future Schemas (SchemaX) are added or even possibly removed without having to repeatedly DROP and CREATE TableView over and over.
Is it possible to create the View in such a way that it would automatically query all tables with the same name? Or perhaps there is some way to 'add' an additional table post creation?
I can get a list of all SchemaX.Table by querying INFORMATION_SCHEMA, but other than having a python script DROP and CREATE the View again I am lost.
Thanks
Thanks for #larnu's comments, it's very useful and professional:
To achieve this dynamically, it would be impossible to do in a VIEW.
You would have to use a stored procedure, and that means you can't do
simple things like SELECT from it, making it far harder to use.
Instead of having 17 tables, all identical, on different schemas you
have one table, with a column BusinessName. Instead of
MySmartCompany.Mytable you have a column in the table dbo.MyTable (or
your generic schema), called BusinessName which has the value 'MySmartCompany'.
This also can be beneficial to other community members.

SQL Server - How to delete the view statement after creating view in database

We can use Encription to hide the view statement, like
CREATE VIEW TestTable
WITH ENCRYPTION
AS
SELECT *
FROM employees
In this way, we cannot find the scripts for creating view from 'Script view as -> Create to '.
Except for Encryption, is there any way to directly drop the view statement while creating view table?
For instance, after creating a view table, people can find the script of how the view is created by selecting 'Script view as -> Create to'. I mean we can use Encryption to hide the database code, but how to directly delete those database code of view statement. And the select * from TestTable should not be affected.
it seems you need revoke view DEFINITION , you may try like below
USE your_database;
REVOKE VIEW DEFINITION FROM user_name CASCADE;
GO
You cannot hide the definitions from DBAs/SA/DBO but you can put permissions to limit access.
You cannot create a script of Encrypted View on SQL Server following the way of
So your code that forms the View's SELECT query is safe
Of course there are third party tools used to decrypt encrypted views source code on SQL Server.
So in fact, there is not a way of reading the source code explicitely for an encrypted object on SSMS
By the way, "DROP VIEW viewname" will only delete the targeted SQL object
There is not a command to drop all views in one statement like "drop views", etc.

Why we need trigger to delete from View?

Sometimes I found some code that makes triggers to allow user to delete from View ?
But why we need to delete from View ,, because simply we can Go to Table > and execute delete like this simple code :
delete from table where x=y ;
My question why we use deletion on views by using TRIGGERS ؟
in another words what is the advantages of using delete over a View !
The reason we use view are mainly to hide the complexity of data
sources , Hide away the actual tables (For security reasons), saving
us writing the same code over and over again.
Now if you havent let your users access the tables directly and they
only work through View in this case they will be executing Deletes
against views.
Triggers are only used when your View has more than One underlying
table. You cannot do update, insert or delete operations on view if it
effects multiple underlying tables. Therefore we make use of Instead
of Delete/Update/Insert Triggers to do these operations against
views.
When you have multiple Underlying tables if you Update,Delete or
Insert effects only One underlying table it does allow you to execute
the statement but it is not guaranteed that it will be done correctly.
therefore if you have a situation where your view is based on
multiple underlying tables you should always do update/delete/inserts
1) Directly to underlying tables. 2) Use Instead of triggers.
Also Read here for more details on why you shouldnt do update/delete/insert operations on views with multiple underlying tables.

Modifying a view to modify a base relation to which I don't have permissions

Let's say I have a permissions to update a view, where the view is:
create view v as select * from Student where major like '%Engineering%'.
I don't have permissions to modify or view any student whose major does not contain the word "Engineering." Should I be allowed to insert into this view even if the major of the student I'm inserting is 'Biology'? Would the view propagate to the base relation?
It depends on the database engine and how the view was created.
Your original view definition will allow Oracle and SqlServer users to insert a view row that the user cannot see, and or update a view row such that a row can no longer be seen.
But you can add the WITH CHECK OPTION to the view in Oracle and SqlServer to prevent users from inserting or updating a view row such that the result is not visible:
create view v as select * from Student where major like '%Engineering%' with check option;
I've just tried it on SQL Server 2008 - the inserted row does propagate to the underlying table.
Obviously you won't be able to see your new row when selecting from your view though.