>I don't understand how you're making this conclusion from what I said. If the maximum size of data is 10 chars, then varchar(10) will work fine.
> vachar(10) takes less space than char(10) but you may not see it immediately, perhaps after index re-build.

If I add a VarChar(10) field on this 26 million record table, I assume SQL Server to optimize right away, at least some kind of optimization, in regards to disk space, as oppose to someone who would use the regular Char(10) field instead. And, then, moving on with the application, as additional records gets added, SQL Server will optimize as needed in regards to disk space saving where the Char(10) field wouldn't allow SQL Server to do so. I hope this is better clear now as far as my explanations. :)

>Also, if your data were originally char, just switching to varchar will not help. You may need to remove all trailing spaces in all data first.

In my case, this would be a new field. But, what you mention is interesting. If I understand correctly, when comes time to change an existing field from Char(10) to VarChar(10), after the design has been saved, we should then replace all the existing records on that field with a trim of its value. Is that correct?