Don Peterson


SQLServerCentral Article

Is XML the Answer?

New Author! Don Peterson writes his first article for us and explores why he considers XML to be...bad! There are some interesting points made here and if you've haven't thought about what XML means to you as a DBA, it's a subject worth spending some time on.

(79)

You rated this post out of 5. Change rating

2008-05-02 (first published: )

64,754 reads

SQLServerCentral Article

Beware of Search Argument (SARG) Data Types

Performance tuning often seems like it can be more of an art than a science. However there are a number of fundamentals that can help you tune most of the queries that you will write or have issues with their performance. Don Peterson brings us a look at how he tuned a query in the real world to avoid a conversion that can cause a query to run slower.

(6)

You rated this post out of 5. Change rating

2006-07-13

11,863 reads

SQLServerCentral Article

Lookup Table Madness

Are you mad? Not angry, more like crazy when it comes to designing databases in SQL Server? Don Peterson has met a few people he thinks are just that when it comes to building lookup tables. Does it stem from poor understanding of database design? Or do you disagree? Read Don's case against this particular design practice.

(27)

You rated this post out of 5. Change rating

2006-03-24 (first published: )

52,275 reads

SQLServerCentral Article

All About Transactions - Part 3

Transactions in SQL Server are probably no more complicated than those in other RDBMS products, which is to say they are fairly complex. Don Peterson continues with part 3 of his series and takes a look at transaction isolation levels and how they interact with multiple connections and their impact on locking.

(9)

You rated this post out of 5. Change rating

2004-12-02

15,937 reads

SQLServerCentral Article

All About Transactions - Part 1

The heart of an RDBMS is the transaction system that it employs. SQL Server has a great one that can easily be misunderstood or misused by those that haven't spent time delving into the details of how it works. Don Peterson has done that and brings us the start of a new series on the details of how transactions work in SQL Server.

(13)

You rated this post out of 5. Change rating

2004-11-15

24,908 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