From 49aa2aa11e3729b1d1ce09a5d63342252e43c72e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E1=83=A6=28=20=C2=B4=EF=BD=A5=E1=B4=97=EF=BD=A5=60=20=29?=
 <40357629+culushishui@users.noreply.github.com>
Date: Sat, 14 Mar 2026 21:46:37 +0800
Subject: [PATCH] Update pages-and-extents-architecture-guide.md

Are you sure that is  moving row ?
---
 .../pages-and-extents-architecture-guide.md                     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/relational-databases/pages-and-extents-architecture-guide.md b/docs/relational-databases/pages-and-extents-architecture-guide.md
index f8d0ccaa704..b52322e6544 100644
--- a/docs/relational-databases/pages-and-extents-architecture-guide.md
+++ b/docs/relational-databases/pages-and-extents-architecture-guide.md
@@ -70,7 +70,7 @@ For example, a table can be created with two columns: one **varchar(7000)** and
 
 When a table or an index has **varchar**, **nvarchar**, **varbinary**, **sql_variant**, or CLR user-defined type columns that can exceed 8,060 bytes per row, consider the following:
 
-- Moving large rows to another page occurs dynamically as rows are lengthened based on update operations. Update operations that shorten rows can cause them to be moved back to the original page in a `IN_ROW_DATA` allocation unit.
+- Moving large colums to another page occurs dynamically as rows are lengthened based on update operations. Update operations that shorten rows can cause them to be moved back to the original page in a `IN_ROW_DATA` allocation unit.
 
   This data movement results in extra disk I/O. Query processing operations such as sorts or joins on large records that contain row-overflow data might be slower.