CHARINDEX returns zero in TEXT column

I'm running into an issue where CHARINDEX on a text datatype column returns
0
if the expression I'm searching for exists at a position greater than 8000.
For example:
use pubs;
select charindex('New Moon Books',pr_info,8000)
from pub_info
returns zero, even though I know 'New Moon Books' exists past character
8000. Is this a known issue, and is there a workaround? It's causing my
search and replace procedure (using the UPDATETEXT function) to fail, i.e.
LIKE '%searchfor%'
is true but
CHARINDEX('searchfor',textColumn)
is zero.
Any help is appreciated.Did you try PATINDEX?
"Alan Smithee" <AlanSmithee@.discussions.microsoft.com> wrote in message
news:F8D5F76C-9114-47F1-A584-96035BFA38B6@.microsoft.com...
> I'm running into an issue where CHARINDEX on a text datatype column
> returns 0
> if the expression I'm searching for exists at a position greater than
> 8000.
> For example:
> use pubs;
> select charindex('New Moon Books',pr_info,8000)
> from pub_info
> returns zero, even though I know 'New Moon Books' exists past character
> 8000. Is this a known issue, and is there a workaround? It's causing my
> search and replace procedure (using the UPDATETEXT function) to fail, i.e.
> LIKE '%searchfor%'
> is true but
> CHARINDEX('searchfor',textColumn)
> is zero.
> Any help is appreciated.|||CHARINDEX will not work for strings larger than 8000. To work with TEXT
fields larger than this size, you will need to use the TEXT functions in SQL
Server 2000 like READTEXT, WRITETEXT etc.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"Alan Smithee" <AlanSmithee@.discussions.microsoft.com> wrote in message
news:F8D5F76C-9114-47F1-A584-96035BFA38B6@.microsoft.com...
> I'm running into an issue where CHARINDEX on a text datatype column
> returns 0
> if the expression I'm searching for exists at a position greater than
> 8000.
> For example:
> use pubs;
> select charindex('New Moon Books',pr_info,8000)
> from pub_info
> returns zero, even though I know 'New Moon Books' exists past character
> 8000. Is this a known issue, and is there a workaround? It's causing my
> search and replace procedure (using the UPDATETEXT function) to fail, i.e.
> LIKE '%searchfor%'
> is true but
> CHARINDEX('searchfor',textColumn)
> is zero.
> Any help is appreciated.|||charindex won't work with text datatype. Use patindex|||Thanks Aaron, you of course are correct, PATINDEX works! (I was sure I had
tried that before, but I think I left out the wildcard character).
Anyway, much thanks (and thanks to Omnibuzz too!)
A.S.
"Aaron Bertrand [SQL Server MVP]" wrote:

> Did you try PATINDEX?
>
> "Alan Smithee" <AlanSmithee@.discussions.microsoft.com> wrote in message
> news:F8D5F76C-9114-47F1-A584-96035BFA38B6@.microsoft.com...
>
>

CHAR vs. VARCHAR

What are the pros & cons of each datatype (char and varchar)?
I have several reference (lookup) tables that use the varchar. Would there
be any reason to convert these to char datatypes?Hi Wes,
It depends what you are doing, if your data is of fixed length, say a 8
letter code then use CHAR, there isn't the overhead (abeit small) of keeping
track of the varying length.
Varchar is good for text that is of varying length, for instance comments,
subject, titles etc... and can save significant space, if you made a title
char(500) then all the rows would be 500 bytes for that column (a lot of
wasted space).
Enter nvarchar and nchar; these are the recommended types to use in SQL
Server now and some things in Integration Services like the text extraction
require them. nchar/nvarchar stores 2 bytes per character and is for unicode
character sets. Personally, i dislike it as the systems i use aren't going
to require the 2 bytes, but for big multi-national stuff its the way
forward.
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Wes" <Wes@.discussions.microsoft.com> wrote in message
news:06343322-86C2-444F-8149-7AA05F4A32DA@.microsoft.com...
> What are the pros & cons of each datatype (char and varchar)?
> I have several reference (lookup) tables that use the varchar. Would
> there
> be any reason to convert these to char datatypes?
>|||http://www.aspfaq.com/2354
http://tinyurl.com/cvtjm
"Wes" <Wes@.discussions.microsoft.com> wrote in message
news:06343322-86C2-444F-8149-7AA05F4A32DA@.microsoft.com...
> What are the pros & cons of each datatype (char and varchar)?
> I have several reference (lookup) tables that use the varchar. Would
> there
> be any reason to convert these to char datatypes?
>|||Tony,
You say that nchar & nvarchar are the recommended types now. Does this have
something to do with Sql Server 2005? If not, then why is this the
recommendation?
"Wes" wrote:

> What are the pros & cons of each datatype (char and varchar)?
> I have several reference (lookup) tables that use the varchar. Would ther
e
> be any reason to convert these to char datatypes?
>|||To add, fixed length datatypes internally consume the whole defined size
regardless of what you actually store in them. Variable length datatypes
physically consume only what you store in them, plus 2 bytes per column used
as an offset.
When you modify a value of a fixed type value, there will never be a need
for the storage space to expand. When you modify a variable type value, to a
longer one, it will need to physically expand the storage space, which might
result in a page split if the row resides in an index (clustered or
nonclustered), and there's no room for the expanded row in the page. If the
table is a heap (no clustered index), SQL Server will need to move the row
to a new location and leave a forwarding pointer in the original slot.
So generally speaking, in terms of modifications, fixed length types are
more appropriate.
On the other hand, fixed length types typically consume more space because
the always utilize the defined size. So retrieval of data typically results
in less I/O with variable length types.
So generally speaking, in terms of retrieval, variable length columns are
more appropriate.
Of course, in mixed systems where you do both modifications and retrievals
you need to prioritize what's more important to you, and in which types of
activities the systems suffers more.
BG, SQL Server MVP
www.SolidQualityLearning.com
Join us for the SQL Server 2005 launch at the SQL W in Israel!
[url]http://www.microsoft.com/israel/sql/sqlw/default.mspx[/url]
"Wes" <Wes@.discussions.microsoft.com> wrote in message
news:06343322-86C2-444F-8149-7AA05F4A32DA@.microsoft.com...
> What are the pros & cons of each datatype (char and varchar)?
> I have several reference (lookup) tables that use the varchar. Would
> there
> be any reason to convert these to char datatypes?
>|||> You say that nchar & nvarchar are the recommended types now. Does this
> have
> something to do with Sql Server 2005? If not, then why is this the
> recommendation?
Because people are finally realizing that not all data is American, and does
not fit nicely in the character set support by non-Unicode data types.|||examnotes <Wes@.discussions.microsoft.com> wrote in
news:CE34A109-71C6-40B2-BEB1-1EE1F524E14E@.microsoft.com:

> You say that nchar & nvarchar are the recommended types now. Does
> this have something to do with Sql Server 2005? If not, then why is
> this the recommendation?
nchar and nvarchar is Unicode, and thus allows for storing character data
from other languages than English without any trouble. For instance, most
of you guys (Except Sommarskog) could possible have troble saving my
surname using char or varchar :)
When using unicode you can save information with different character sets,
as for instance nordic (my surname), gr and cyrillic. Of course, at the
cost of some extra bytes.
Ole Kristian Bangs
MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging|||I should also add that since these are lookup tables which are very small
anyway there are special considerations. If the typical types of access
methods against those are index s operations, read performance won't
really be affected by the choice of fixed/dynamic columns.
Also, comparing the physical I/O against the data tables vs. the lookup
tables, the lookups' part is typically very small.
BG, SQL Server MVP
www.SolidQualityLearning.com
Join us for the SQL Server 2005 launch at the SQL W in Israel!
[url]http://www.microsoft.com/israel/sql/sqlw/default.mspx[/url]
"Itzik Ben-Gan" <itzik@.REMOVETHIS.SolidQualityLearning.com> wrote in message
news:OaSbj1y3FHA.128@.tk2msftngp13.phx.gbl...
> To add, fixed length datatypes internally consume the whole defined size
> regardless of what you actually store in them. Variable length datatypes
> physically consume only what you store in them, plus 2 bytes per column
> used as an offset.
> When you modify a value of a fixed type value, there will never be a need
> for the storage space to expand. When you modify a variable type value, to
> a longer one, it will need to physically expand the storage space, which
> might result in a page split if the row resides in an index (clustered or
> nonclustered), and there's no room for the expanded row in the page. If
> the table is a heap (no clustered index), SQL Server will need to move the
> row to a new location and leave a forwarding pointer in the original slot.
> So generally speaking, in terms of modifications, fixed length types are
> more appropriate.
> On the other hand, fixed length types typically consume more space because
> the always utilize the defined size. So retrieval of data typically
> results in less I/O with variable length types.
> So generally speaking, in terms of retrieval, variable length columns are
> more appropriate.
> Of course, in mixed systems where you do both modifications and retrievals
> you need to prioritize what's more important to you, and in which types of
> activities the systems suffers more.
> --
> BG, SQL Server MVP
> www.SolidQualityLearning.com
> Join us for the SQL Server 2005 launch at the SQL W in Israel!
> [url]http://www.microsoft.com/israel/sql/sqlw/default.mspx[/url]
>
> "Wes" <Wes@.discussions.microsoft.com> wrote in message
> news:06343322-86C2-444F-8149-7AA05F4A32DA@.microsoft.com...
>|||Great feedback from everyone. Thanks.
"Itzik Ben-Gan" wrote:

> To add, fixed length datatypes internally consume the whole defined size
> regardless of what you actually store in them. Variable length datatypes
> physically consume only what you store in them, plus 2 bytes per column us
ed
> as an offset.
> When you modify a value of a fixed type value, there will never be a need
> for the storage space to expand. When you modify a variable type value, to
a
> longer one, it will need to physically expand the storage space, which mig
ht
> result in a page split if the row resides in an index (clustered or
> nonclustered), and there's no room for the expanded row in the page. If th
e
> table is a heap (no clustered index), SQL Server will need to move the row
> to a new location and leave a forwarding pointer in the original slot.
> So generally speaking, in terms of modifications, fixed length types are
> more appropriate.
> On the other hand, fixed length types typically consume more space because
> the always utilize the defined size. So retrieval of data typically result
s
> in less I/O with variable length types.
> So generally speaking, in terms of retrieval, variable length columns are
> more appropriate.
> Of course, in mixed systems where you do both modifications and retrievals
> you need to prioritize what's more important to you, and in which types of
> activities the systems suffers more.
> --
> BG, SQL Server MVP
> www.SolidQualityLearning.com
> Join us for the SQL Server 2005 launch at the SQL W in Israel!
> [url]http://www.microsoft.com/israel/sql/sqlw/default.mspx[/url]
>
> "Wes" <Wes@.discussions.microsoft.com> wrote in message
> news:06343322-86C2-444F-8149-7AA05F4A32DA@.microsoft.com...
>
>|||Ole,
But the non-Unicode Latin1 datatypes *does* support the Nordic characters, a
long with the "western
European" characters.
(But you will of course run into problems when you get into eastern Europe,
and of course Russia,
Asia etc.)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Ole Kristian Bangs" <olekristian.bangas@.masterminds.no> wrote in message
news:Xns9701E9167880Folekristianbangaas@.
207.46.248.16...
> examnotes <Wes@.discussions.microsoft.com> wrote in
> news:CE34A109-71C6-40B2-BEB1-1EE1F524E14E@.microsoft.com:
>
> nchar and nvarchar is Unicode, and thus allows for storing character data
> from other languages than English without any trouble. For instance, most
> of you guys (Except Sommarskog) could possible have troble saving my
> surname using char or varchar :)
> When using unicode you can save information with different character sets,
> as for instance nordic (my surname), gr and cyrillic. Of course, at the
> cost of some extra bytes.
> --
> Ole Kristian Bangs
> MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging

Char Format

I have one table that has a column 'amount' with datatype 'numeric(19,5)'
I'm want to insert the data from this column into another column (in a different database) with this format: '00000000.00' as 'char'
example: If in the first column I have 800.75864 I want to insert it in the other column as '00000800.75'

any suggestions on how to make this conversion?This is freaking blowing my mind...

This should work

DECLARE @.x decimal(15,5), @.y char(11)
SELECT @.x = 800.75864
SELECT @.x, RIGHT(REPLICATE('0',11)+CONVERT(char(11),CONVERT(d ecimal(15,2),@.x)),11)

But's it's acting like it's doing an implicint conversion to numeric...

Hold on..

If I do...

DECLARE @.x decimal(15,5), @.y char(11)
SELECT @.x = 800.75864
SELECT @.x, REPLICATE('0',11)+CONVERT(char(11),@.x)|||If you just need the rounding, then check the round (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ra-rz_93z8.asp) function. If you need zero padding too (which is rather silly in most cases, since SQL Server handles all of the "leading zero" issues for you), then you'll probably have to resort to a user defined function.

-PatP|||Methinks thou meant:DECLARE @.x decimal(15,5), @.y char(11)
SELECT @.x = 800.75864
SELECT @.x, RIGHT(REPLICATE('0',11)+CONVERT(varchar(11),CONVER T(decimal(15,2),@.x)),11)That works, as long as the value to convert is positive... Then you get some "interesting" results as the sign floats about!

-PatP|||Yeah...what an idiot...

char(11)...

just found the prob...

Thanks...|||It is the "little" things that make the biggest boom when you trip over them!

-PatP|||declare @.n numeric(19,5)
set @.n = 800.75864
SELECT REPLACE(STR(@.n-.005,11,2),' ','0')

Hans.|||THANKS A LOT! IT WORKED|||Originally posted by diegocro
THANKS A LOT! IT WORKED

What did you expect?

And which one did you use?|||Both, I've been trying to do this since yestarday, that's why I was happy.|||Well that'll learn ya

char datatype padding

I noticed that when creating a char(5) field in SQL 2005 it places any
padding on the right of the value in there...for example I put in a value =
'50' and when I do a select on it with single quotes surrounding the value it
returns '50 ' . I was just wondering if that is a setting in SQL that can
be changed to have the padding at the front of the value instead at the end?
Or, what is a good way of getting that padding at to the front?
Thanks in advance,
John Scott.
John Scott,
It looks like you want 'numeric' formatting, so you could change from a
CHAR(5) to an INT or another appropriate numeric type and let the UI format
it for you. If you really want want you describe, however, you can:
RIGHT(' ' + RTRIM(YourColumn), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> =
> '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.
|||Of course, that falls apart if somebody typed leading blanks. Such as would
be the case after one edit. So...
RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> =
> '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.
|||Thanks for the help Russell!!
Thanks,
John Scott.
"Russell Fields" wrote:

> Of course, that falls apart if somebody typed leading blanks. Such as would
> be the case after one edit. So...
> RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
> RLF
> "John Scott" <johnscott@.despammed.com> wrote in message
> news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>
>

char datatype padding

I noticed that when creating a char(5) field in SQL 2005 it places any
padding on the right of the value in there...for example I put in a value =
'50' and when I do a select on it with single quotes surrounding the value i
t
returns '50 ' . I was just wondering if that is a setting in SQL that can
be changed to have the padding at the front of the value instead at the end?
Or, what is a good way of getting that padding at to the front?
Thanks in advance,
John Scott.John Scott,
It looks like you want 'numeric' formatting, so you could change from a
CHAR(5) to an INT or another appropriate numeric type and let the UI format
it for you. If you really want want you describe, however, you can:
RIGHT(' ' + RTRIM(YourColumn), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> =
> '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.|||Of course, that falls apart if somebody typed leading blanks. Such as would
be the case after one edit. So...
RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> =
> '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.|||Thanks for the help Russell!!
--
Thanks,
John Scott.
"Russell Fields" wrote:

> Of course, that falls apart if somebody typed leading blanks. Such as wou
ld
> be the case after one edit. So...
> RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
> RLF
> "John Scott" <johnscott@.despammed.com> wrote in message
> news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>
>

char datatype padding

I noticed that when creating a char(5) field in SQL 2005 it places any
padding on the right of the value in there...for example I put in a value = '50' and when I do a select on it with single quotes surrounding the value it
returns '50 ' . I was just wondering if that is a setting in SQL that can
be changed to have the padding at the front of the value instead at the end?
Or, what is a good way of getting that padding at to the front?
--
Thanks in advance,
John Scott.John Scott,
It looks like you want 'numeric' formatting, so you could change from a
CHAR(5) to an INT or another appropriate numeric type and let the UI format
it for you. If you really want want you describe, however, you can:
RIGHT(' ' + RTRIM(YourColumn), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> => '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.|||Of course, that falls apart if somebody typed leading blanks. Such as would
be the case after one edit. So...
RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
RLF
"John Scott" <johnscott@.despammed.com> wrote in message
news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
>I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value
> => '50' and when I do a select on it with single quotes surrounding the value
> it
> returns '50 ' . I was just wondering if that is a setting in SQL that
> can
> be changed to have the padding at the front of the value instead at the
> end?
> Or, what is a good way of getting that padding at to the front?
>
> --
> Thanks in advance,
> John Scott.|||Thanks for the help Russell!!
--
Thanks,
John Scott.
"Russell Fields" wrote:
> Of course, that falls apart if somebody typed leading blanks. Such as would
> be the case after one edit. So...
> RIGHT(' ' + LTRIM(RTRIM(YourColumn)), 5)
> RLF
> "John Scott" <johnscott@.despammed.com> wrote in message
> news:9CFED437-37A2-4157-A6D9-BC7051AD6ED1@.microsoft.com...
> >I noticed that when creating a char(5) field in SQL 2005 it places any
> > padding on the right of the value in there...for example I put in a value
> > => > '50' and when I do a select on it with single quotes surrounding the value
> > it
> > returns '50 ' . I was just wondering if that is a setting in SQL that
> > can
> > be changed to have the padding at the front of the value instead at the
> > end?
> > Or, what is a good way of getting that padding at to the front?
> >
> >
> > --
> > Thanks in advance,
> >
> > John Scott.
>
>|||John,
Although there are ways to do this, you have to ask yourself if it is a
good idea. IMO, it is a bad idea. You would need such code whereever you
are handling the column, or you might get incorrect results. For
example, image a search query like this:
SELECT ...
FROM my_table
WHERE my_char5_column = @.val
If you simply use the standard behavior (right padding of spaces), this
will all work as expected, but if you change the formula, then it is all
up to get to get everything right (including how to handle strings that
are too long).
If you need left padding and no right padding, then you should do this
in the front-end application. If you must do it in the database, then I
suggest you create a computed column for it, just for display purposes.
For example:
ALTER TABLE my_table
ADD my_leftpadded_char5_column AS
RIGHT(SPACE(5)+RTRIM(my_char5_column),5)
HTH,
Gert-Jan
John Scott wrote:
> I noticed that when creating a char(5) field in SQL 2005 it places any
> padding on the right of the value in there...for example I put in a value => '50' and when I do a select on it with single quotes surrounding the value it
> returns '50 ' . I was just wondering if that is a setting in SQL that can
> be changed to have the padding at the front of the value instead at the end?
> Or, what is a good way of getting that padding at to the front?
> --
> Thanks in advance,
> John Scott.

Char and VarChar Datatype

Hi ,
What is the diff within Char and Varchar ? If define Char(10) in TableA
and this field is store the State code and the length is a non standard. User
can key in the length from 1 to 10.
Understand that I should define this field as VarChar(10) because is it a
no fixed length. But I don't really undertand what is the diff between this
two datatype in the backend structure ? It save the space ?
Travis Tan
In the backend char(10) is always stored as 10 characters (bytes), which
can give you problems when doing string comparisons because the string
will be padded with trailing spaces.
Varchar(10) will store a 32 bit integer (4 bytes) at the front of the
field to indicate the field length, followed by the actual number of
characters in the string.
So if you store a 2 character string in a varchar(10) it will use 6
bytes storage, if you store a 10 character string it will store 14
bytes.
HTH
Regards
Darren Gosbell [MCSD]
<dgosbell_at_yahoo_dot_com>
Blog: http://www.geekswithblogs.net/darrengosbell

Char and VarChar Datatype

Hi ,
What is the diff within Char and Varchar ? If define Char(10) in TableA
and this field is store the State code and the length is a non standard. Use
r
can key in the length from 1 to 10.
Understand that I should define this field as VarChar(10) because is it a
no fixed length. But I don't really undertand what is the diff between this
two datatype in the backend structure ? It save the space ?
Travis TanIn the backend char(10) is always stored as 10 characters (bytes), which
can give you problems when doing string comparisons because the string
will be padded with trailing spaces.
Varchar(10) will store a 32 bit integer (4 bytes) at the front of the
field to indicate the field length, followed by the actual number of
characters in the string.
So if you store a 2 character string in a varchar(10) it will use 6
bytes storage, if you store a 10 character string it will store 14
bytes.
HTH
Regards
Darren Gosbell [MCSD]
<dgosbell_at_yahoo_dot_com>
Blog: http://www.geekswithblogs.net/darrengosbell