Content area
In the view defined here, we've converted the resume field from the text data type into a varchar that can be up to 8,000 characters in length. (Note that this trick won't work in earlier versions of SQL Server. They limit the varchar type to 255 characters. Version 7, however, puts the cap at 8,000 characters.) You can then select from the view instead of the table, and get back up to 8,000 characters of your data.
Full text
If you're like just about every other SQL Server user, you've probably upgraded to SQL Server 7. If so, you might have noticed that some of your ASP sites have started behaving strangely. Specifically, you might be finding that the data that's being saved into the text fields of your database appear to be chopped off after about 255 characters.
Where did the data go?
Actually, there are a couple of possible culprits here. First, if you're presenting your data in a simple text box (), you'll find that it simply can't handle really long text strings. The easiest solution to this problem is to display your data in a
If that doesn't seem to solve the issue, you might be facing a much more subtle problem. Namely, you might not be getting back all of your data when you query your database! So, for example, a user types 1,000 characters into a field, which you save. Then, when you query the database and present that data to the user for editing, he only sees the first couple hundred characters. If the user subsequently saves this data without noticing the problem, all those other characters will be lost!
If you're experiencing this problem, there are a couple of things you can do, as shown in Figure A. First, check the SQL Server variable "@@textsize". This variable tells you how many bytes will be returned in any text fields that you query with a select statement. This value is supposed to default to 4,096, but if it doesn't, you can easily reset it by executing the SQL statement
Of course, you can substitute some other number for 4,096, up to about 2 billion. (You can also use 0 [zero] to reset textsize to the default of 4,096.) If this doesn't seem to work, there's another trick you can use to get back all of your data. Instead of querying your table directly, use a view. For example, consider the table shown in Figure B and the table and view definitions in Listing A.
In the view defined here, we've converted the resume field from the text data type into a varchar that can be up to 8,000 characters in length. (Note that this trick won't work in earlier versions of SQL Server. They limit the varchar type to 255 characters. Version 7, however, puts the cap at 8,000 characters.) You can then select from the view instead of the table, and get back up to 8,000 characters of your data.
One last solution
Of course, there are going to be some text fields with more than 8,000 characters in them. For those situations, you can use a very simple trick that makes creating a view unnecessary. The secret to this trick is the fact that IIS3 and IIS4 both seem to lose track of the data in a text column as soon as you try to access it. So, what you have to do is save the value of any text field to a local variable before you access or use it in any other way. For example, instead of this:
Putting it all together
Listing B, on the next page, is a simple ASP script that demonstrates these concepts with three simple queries. You can see the results in Figure A. The first query simply fetches all of the data from our table and then echoes it to the client in a simple table formal. You'll notice that even though the lengths of our resume columns are reported as 45 and 12,710, respectively, nothing shows up in our table.
The second query merely changes the source of our data to the view that we defined in Figure B. In this case, we have data showing up in our HTML controls, but the second resume has been chopped off at 8,000 characters. So, we need to pursue our final remedy.
The last query is identical to the first, but if you look closely at Listing B, you'll see that we process the results a bit differently. Instead of simply echoing the data to the client, we first extract the data from each field to determine it's length, and then present it to the client in the appropriate fashion. Of course, it's almost impossible to present the entire contents of the complete resume field in a simple screen shot like we have here, but we can assure you that the entire contents of the resume field are in the
Get unruly text fields under control
We've seen several different approaches to dealing with unruly text fields here, one of which will likely solve any problems you've encountered. Just in case you're wondering, most of these tricks (with the exception of the view solution) will work with previous versions of SQL Server as well as SQL Server 7. So, if your text fields have been giving you trouble, try out some of these solutions and get them back under control!
Copyright ZD Journals Nov 2000