Always Encrypted

SQLServerCentral Editorial

High Prices for High Security

  • Editorial

I was excited to see the new Secure Enclave technology come to Always Encrypted (AE) in SQL Server 2019. I've thought that the way Microsoft implemented the AE technology in SQL Server 2016 was a start and a good step forward, but it had too many restrictions. Kind of like Availability Groups in 2012 and […]

You rated this post out of 5. Change rating

2019-05-30

460 reads

External Article

SQL Server Encryption: Always Encrypted

  • Article

Is 'Always Encrypted' SQL Server 2016's most widely important new feature? It is significant that 'Always Encrypted' in SQL Server is in all editions of SQL Server. Because of the increasing importance of encryption to data governance, it allows encryption for the sensitive application data for everywhere beyond the application's client connection, including network, server, database and storage. Robert Sheldon explains what it is, why you should try it out, and how to set about it.

2017-04-10

4,486 reads

Blogs

Why Optimize CPU for RDS SQL Server is a game changer

By

One feature that I have been waiting for years! The new announcement around optimize...

Performance tuning KubeVirt for SQL Server

By

Following on from my last post about Getting Started With KubeVirt & SQL Server,...

T-SQL Tuesday #193 – A Note to Your Past, and a Warning from Your Future

By

I haven’t posted in a while (well, not here at least since I’ve been...

Read the latest Blogs

Forums

Refactoring SQL Code

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Refactoring SQL Code, which is...

The Read Committed Snapshot Isolation behaviour

By Alessandro Mortola

Comments posted to this topic are about the item The Read Committed Snapshot Isolation...

Working with JSON/JSONB Data in PostgreSQL using Python

By sabyda

Comments posted to this topic are about the item Working with JSON/JSONB Data in...

Visit the forum

Question of the Day

The Read Committed Snapshot Isolation behaviour

I am currently working with Sql Server 2022 and AdventureWorks database. First of all, let's set the "Read Committed Snapshot" to ON:

use master;
go

alter database AdventureWorks set read_committed_snapshot on with no_wait;
go
Then, from Session 1, I execute the following code:
--Session 1
use AdventureWorks;
go

create table ##t1 (id int, f1 varchar(10));
go

insert into ##t1 values (1, 'A');
From another session, called Session 2, I open a transaction and execute the following update:
--Session 2
use AdventureWorks;
go

begin tran;
update ##t1 
set f1 = 'B'
where id = 1;
Now, going back to Session 1, what happens if I execute this statement?
--Session 1
select f1
from ##t1
where id = 1;
 

See possible answers