SQL Saturday Chattanooga 2017
Second of the year, I will be presenting at SQL Saturday Chattanooga 2017. Come see my SQL Server 2017 (Linux and Beyond) session
2017-04-19
9 reads
Second of the year, I will be presenting at SQL Saturday Chattanooga 2017. Come see my SQL Server 2017 (Linux and Beyond) session
2017-04-19
9 reads
Today I am very excited to announce that I have (finally!) launched my email course covering the basics of SQL...
2017-04-19
337 reads
It’s official: the next version of SQL Server, planned to be released this year, will be called SQL Server 2017....
2017-04-19
3,384 reads
I’ve been testing the SQL Server on Linux for a long time. After the recent Microsoft Data Amp event, I...
2017-04-19
862 reads
A while back, I was building the database schema for a web application which had some reporting functionality and among other things, I had do implement logic in the...
2017-04-19
15 reads
A while back, I was building the database schema for a web application which had some reporting functionality and among...
2017-04-19
12,479 reads
The latest article on SQLShack continues on the path of Data Warehouse development with SQL Server Analysis Services. The first...
2017-04-19
504 reads
This month’s T-SQL Tuesday is hosted by yours truly! The topic this month: how do you keep up with the...
2017-04-19 (first published: 2017-04-11)
1,754 reads
Taking a short break from the Database Fundamentals series of the last few weeks, I’d like to mention some upcoming...
2017-04-19
114 reads
The other day I needed to test some HADR requirements on my local machine so using VirtualBox, I created a...
2017-04-19
2,784 reads
With Fabric Mirroring, Microsoft is promoting a nice and appealing story for operational reporting...
If you’ve been watching AI roll through the data community and thinking, “this seems...
By Arun Sirpal
Not every production incident is a database in RECOVERY_PENDING or a corrupted event (like...
Comments posted to this topic are about the item SQL Art, Part 4: Happy...
Hi All I am trying to find 'bad' characters that users might type in....
Comments posted to this topic are about the item Extreme DAX: Take your Power...
I set up a few users on my SQL Server 2022 instance.
CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1' CREATE USER User1 FOR LOGIN User1 GO CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2' CREATE USER User2 FOR LOGIN User2 GO CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3' CREATE USER User3 FOR LOGIN User3 GOI then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2 GO SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOThis worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3; GOWhat happens with this code?
SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOSee possible answers