I\'ve inherited a asp.net website project that currently runs SQL Server 2000 as its backend.
I\'ve been doing some databases changes on a local copy of the db using
This depends on your needs. You can use a TEXT column instead of VARCHAR(MAX) but you have to be sure that your implementation doesn't need to search on that field, as you cannot do like comparisons on TEXT and NTEXT fields.
If you can limit yourself to 8000 characters, I would use a VARCHAR(8000) column to store the information.
It sounds like the varchar(MAX)
limitations are a moot point if your live DB is SQL Server 2000, which doesn't support them. If you have more than 8K characters to store you are pretty much left with the only other option, a TEXT
column. However, beware that TEXT
columns have a lot of limitations too.
For example you can't sort or group on them easily, nor can you compare them for equivalency with other columns. That is you can't say Select * from mytable where Mytext1 = mytext2
.
Other relevant concerns:
NText
or NVarchar
column regardless of the way you go to support Unicode. varchar(8000)
column is likely to be frequently close to full, you may have problems with the row limit of 8K. Keep this in mind too.Use a TEXT column.
VARCHAR(Max)
was introduced in SQL Server 2005, and will not work on SQL Server 2000. You need to use either VARCHAR(8000)
assuming that will be big enough. Otherwise you will need to use TEXT
Edit
Also if you switch to VARCHAR(8000)
keep in mind there is a limit that a single row cannot have more then 8060 bytes. So if you fill up a varchar(8000)
table and have a bunch of other large columns you will get an error. This is where Text
comes in.
Text
has performance implication because by default it is stored in a separate location, and they keep a pointer in a table. There is a set option which changes this behavior so that text types are kept in the table until they reach a certain size. If you have mostly small blobs you might want to enable this.