When the reporting team needs an assist...
Collect your data from your servers easily using linked servers.
Collect your data from your servers easily using linked servers.
This article is an extract from the book Tribal SQL. In this article, Mark S. Rasmussen offers a concise introduction to the physical storage internals behind SQL Server databases. He doesn't dive into every detail, but provides a simple, clear picture of how SQL Server stores data.
This Friday Steve Jones asks you to network at your next event and meet more people in the amazing SQL Server community.
This article describes a design pattern for storing “effective dated" changes to fact tables.
One of the benefits of running SQL on virtual environment is the capability to present additional vCPUs to the virtual server online and real-time without interruption to running processes. Our VM administrator normally presents only 1 vCPU on the virtual server and extends as required. This article describes how SQL Server is able to detect hot-added vCPUs in my virtual server.
Download the latest preview of the the next SQL Server version for testing.
Steve Jones looks back at a networking event this week in Charlotte. Networking is valuable to your career and it can be a tremendous amount of fun as well.
Dave Lumley presents a Reporting services disaster recovery solution for SQL Server Standard Edition, using 2 servers. Worth the read if you don't run Enterprise.
During weekend maintenance, members of the support team executed an UPDATE statement against the database on the OLTP Server. This database was a part of Transactional Replication, and once the UPDATE statement was executed the Replication procedure came to a halt with an error message. Satnam Singh decided to work on this case and try to find an efficient solution to rebuild the procedure without significant downtime.
Are we thinking cloud first for database servers? Steve Jones reflects on predictions made four years ago and thinks about how the world has changed for the cloud.
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