Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
MichaelP
Jedi Yak
2489 Posts |
 Posted - 2002-06-18 : 12:34:19
|
| I've got a database that was upsized from Access without any changes. Most of the fields are nVarChar. My understanding is that since nVarChar stores Unicode data, it takes up twice the space of a VarChar field.My Question is this:If I have an ADO recordset from a table with nVarChar fields, will it be about twice as big as a recordset from the same table if that table had VarChar fields?Thanks, hope everyone understood that :)Michael |
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2002-06-18 : 13:32:42
|
I think you've answered your own question ...  .If you don't have a need to store international characters, don't.setBasedIsTheTruepath<O> |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-06-18 : 14:01:29
|
| Would I see any performance gains by moving everything to VarChar?Would I only see disk space savings?Michael |
|
|
|
jasper_smith
SQL Server MVP & SQLTeam MVY
846 Posts |
Posted - 2002-06-18 : 14:10:06
|
| Since nvarchar data takes twice the space of varchar then since the Access Upsize wizard tends to convert everything to nvarchar you could save almost half the space currently used. On a page level you could fit almost twice the amount of rows on a page using varchar rather than nvarchar thus each logical I/O would be almost twice as efficent. So in short yes. This is a simplistic explanation but you get the idea HTHJasper Smith |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-06-18 : 14:39:10
|
| I didn't think about 1/2 the I/O required to read the data. That's a good point.Half the Space, Half the I/O. So smaller and faster. Sounds liek we should convert to VarChar. Thanks all!Michael |
|
|
|
|
|
|
nVarchar vs Varchar with ADO