事情開始得很簡單。MegaWare公司市場部門想要一個新的網站來發布文檔，開發團隊覺得使用SQL Server 2000數據庫作為文檔存儲倉庫會使事情變得簡單。Steve是MegaWare的數據庫管理員，沒有看出這有什麼大問題;在數據庫中存儲文檔，而不是使用文件系統，意味著服務器需要多做一些工作，但是它也會使得備份和管理容易得多。數據庫與文件系統變得不同步也應該是不可能的。
市場部門想要存儲的許多文檔都超過了8000個字節，那麼很明顯VARCHAR不是適合這項工作的數據類型。作為替代，TEXT數據類型被用來定義存放數據的字段。因為每個TEXT都能容納2GB的內容，TEXT要存放市場部門的同事們扔進數據庫的最大的文件也是沒有問題的。
數月過去了，市場用大量的無聊拷貝填滿了整個數據庫。但是這還不是Steve真正關心的問題。數據庫愉快地嗡嗡作響地運轉著，每個人對項目的結果都很滿意。
直到公司的標語改變的那個重大的日子。市場部的團隊認為“MegaWare: It's really cool!”要比原來的“It's MegaWare's Way or the Highway!” 聽起來更好。因為市場部團隊已經將原來的標語嵌入了倉庫中每個文檔的頁腳上，現在Steve的工作就是更改所有這些文檔的頁腳。
“沒有問題，” Steve想，打開SQL Server 查詢分析器工具，執行了如下的T-SQL批處理:
UPDATE MarketingDocuments
SET Document =
REPLACE(Document,
'It''s MegaWare''s Way or the Highway!',
'MegaWare: It''s really cool!)
當他看到出現的錯誤消息的時候，Steve的輕松的微笑很快消失了，“替換函數的參數1，text數據類型無效。”
替換函數在編寫出來的時候，就對TEXT數據類型不起作用。同樣也對CHARINDEX或者SUBSTRING不起作用——或者至少是他們在超過8千個字符的情況下不起作用。更進一步地講，開發人員忘了處理TEXT或者IMAGE類型的本地變量;實際上不支持任何操作。即使是簡單地更新一個文檔中的一個子字符串都需要用到晦澀的東西，以及難以使用的類似READTEXT和WRITETEXT的函數。而不是開發人員或者忙碌的數據庫管理員因為想要弄清如何正確使用而采用了不同類型的函數消耗了時間。
SQL Server的開發人員很幸運，他們將會撥開烏雲見藍天。SQL Server 2005引入了一系列新的被稱為MAX的數據類型。這是VARCHAR，NVARCHAR和VARBINARY類型的擴展，這幾種類型以前被限制在8000字節以下。MAX可以容納高達2GB的數據，與TEXT和IMAGE一樣——並且完全兼容所有的SQL Server內置的字符串函數。
用MAX關鍵字定義一個某種MAX類型的變量與替代字符串的尺寸(為VARCHAR/NVARCHAR的時候)或者字節(為VARBINARY的時候)一樣簡單。
DECLARE @BigString VARCHAR(MAX)
SET @BigString = 'abc'
