views:

53

answers:

4

What do I need to consider before I switch a bunch of fields from VARCHAR(bignumber) to TEXT?

Aside from performance, and sometime in the far future TEXT will be deprecated, and aside from the fact that it looks like I need to drop and recreate the table to alter the column's data type?

This is for SQL 2000-- I can't do VARCHAR(max) and VARCHAR(8000) isn't large enough.

+1  A: 

Many T-SQL string functions won't work with text - they only work with char/varchar/nchar/nvarchar.

Daniel Renshaw
+2  A: 

Not sure if you cannot just alter the column's data type:

ALTER TABLE dbo.YourTable
  ALTER COLUMN YourColumn TEXT

Doesn't that work? (not sure if that worked back on 2000.....)

As for things to remember: the TEXT data type also is a lot more cumbersome to work with if you need to do string manipulation, since most if not all the usual string functions like LEN, SUBSTRING etc. don't work on it. So in T-SQL itself, it's a major PIA to work with TEXT columns....

But other than that, you should be fine, I believe.

marc_s
yes, I'm pretty sure this should work to.
Chris Simpson
Hmm, interesting. I was looking at the change script that enterprise manager created after changing the data type. I'll test that idea.
MatthewMartin
+1  A: 

You cannot search the fields, for one, and many queries will not work, which use string manipulation functions. Better to split the field into two or more. Seriously, if that's the only way, because an upgrade to the Express version of SQL Server 2008 would probably be better than sticking with SQL Server 2000 at this point, IMHO. Actually, splitting the fields would just be bad too. Forget that. I would not do it, unless my boss refused to upgrade, then I'd have to pick and choose which fields to VARCHAR(MAX) and which to split up, and which may get away with Text as the type.

Richard Hein
I wish I could, varchar(max) is a much more elegant solution. But big government organizations move at their own pace and I can't hurry them.
MatthewMartin
Too true, been there, done that. Sadly there is not one solution that works for all the fields in general. If some field is used in a stored proc, you need to know about it ... you'll have to find every instance of that field. The refactoring tools in Visual Studio for DB Pros (and whatever they are calling it in 2010), would help, but I don't know what capabilities are present if you use it against 2000. Or if you have RedGate's tools, great, you can find the ones that can't be Text. Good luck. I feel the pain.
Richard Hein
+2  A: 

At least:

Back in ye olden SQL Server 6.5 days, I stored some data in several varchar(255) columns because varchar(8000) was only introduced with SQL Server 7.

Lordy, how did I forget this? It's ugly, but could you manage with a few varchar(8000) coumns concatenated?

gbn
You can't actually fill multiple varchar(8000) columns because you'll hit the 8KB maximum row size. A single 8000 column will use up most of the 8KB.
MatthewMartin
@MatthewMartin: ah, what was I thinking...? Thank you and corrected
gbn
afaik you cannot compare and index text columns, either. the 8k record size limit does not apply to sql2005+
devio
@devio: we are on about SQL Server 2000 says OP. Otherwise we'd not be discussing text/image
gbn