Reverse Engineering Disasters
Preparing a disaster recovery plan means more than just trying to prevent a few specific disasters. It means turning around the way you view the world.
Preparing a disaster recovery plan means more than just trying to prevent a few specific disasters. It means turning around the way you view the world.
The first test of AlwaysOn in SQL Server 2012 is successful, but after testing to swing back again to your primary replica, you find out that automatic failover works only the first time. How come? Carla Abanes explains.
Nobody seems to ask questions about SQL Expressions in forums, even though expressions can cause all sorts of problems. It's time for some straight-forward Q&As, and who better than Robert Sheldon to give the A?
SQL in the City is coming this fall to London and Seattle.
After performing an update on SQL Server, SQL Server Engine and SQL Agent stop responding.
As the enterprise embraces big data, management assumes that staff sizes will decrease. What should be done with those unneeded technologists? One answer: convert them into technology consultants that collaborate and coordinate with the lines of business. In other words, give them customer-facing roles.
SQL Saturday is coming to San Diego on September 20, 2014. This event has a great speaker line-up which includes Itzik Ben-Gan, Grant Fritchey, and many others. Register while space is available.
An SSIS package that can generate an XML file for each record in an XML column in a SQL Server Database using the Source Script Component in a Data Flow Task.
One of the things that can make a big difference in how well your software performs is testing.
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...
It is Friday, the queries are running, and nobody is watching the bill. That...
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....
WhatsApp: 0817839777 Kw. Industri Pulogadung, Jl. Raya Bekasi Km. 21, Ruko No.A2/18-19, RW.3, Wil,...
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