本文是SQL Server 2005关于数据类型最大值问题的处理办法的实例。

　　事情开始得很简单。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的函数。而不是开发人员或者忙碌的数据库管理员由于想要弄清如何正确使用而采用了不同类型的函数耗费了时间。