About this episode
Managing concurrent access to a resource, be it a row, a table, or a single value, is easy if no one is trying to modify the underlying data. But what happens if someone changes data while someone else is reading it? Even better, what could happen if two or more users try to change the same data at the same time? Well, there are a couple of options. The easiest is to just ask everyone to queue up, the other is to have multiple versions of the data available over time so that no one must wait for the changes to be finished. Let's explore both the options with Lara Rubbelke and Davide Mauri on Azure Friday. Chapters 00:00 - Introduction 01:50 - DEMO: Locking behavior 03:20 - DEMO: Default "read committed snapshot" behavior 05:20 - Migrating from SQL Server to Azure SQL DB 06:42 - DEMO: snapshot isolation level 12:12 - Wrap-up Recommended resources Transaction locking and row versioning guide SET TRANSACTION ISOLATION LEVEL (Transact-SQL) Azure SQL Database Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Lara Rubbelke | Twitter: @SQLGal Davide Mauri | Twitter: @MauriDB Azure Friday | Twitter: @AzureFriday
Get every episode summarized
Each time Azure Friday publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
No transcript yet
This episode has not been transcribed. Request it and it moves to the front of the queue.
More episodes
More from Azure Friday
Deploying Aspire Apps to Azure App Service for Linux
Azure Friday
Future-proof Postgres for better performance and scale
Azure Friday
Turning Coding Agents into an Azure Cosmos DB Expert with the Agent Kit
Azure Friday
Meet Azure HorizonDB, the new Postgres on Azure
Azure Friday