nvarchar Data Type

[Michael Visintin]

We used some wizard to convert from an access database to an SQL Server 7.0
database.

No one really thought about the fact that all of the text fields from the
access database were being converted by the wizard to something called
nvarchar.

Typically, our code in the programs hooked into the new database ran fine,
except that we started getting strings that were very long, which seemed to
have blanks padded on the end. We set up a bunch of Trim() statements to
handle the problem, which I doubt will give us any speed improvements.

I now know that an nvarchar is a variable length UNICODE string. I
understand that the future is UNICODE and that the future is now.

However, I am wondering about performance issues. SQL server or VB or both
must be translating this string for us, since we are not noticing problems
with the code other than the extra long strings we are getting.

Are all the string and substring functions in VB UNICODE aware? Are they
translating the nvarchar strings from the SQL Server database for us?

We still have a few machines running Win95, which I believe does not support
UNICODE. Will we encounter trouble there?

We also have programs written in the VB script used by Access which get data
from this database. We also have some ASP code which accesses this
database. Are we going to be OK there?

Bottom line, since this data is English only, should we somehow convert this
data from UNICODE back to char? Will that hurt us in the future? We
attempted to convert by just setting the data type on the database field to
char from nvarchar, but it just truncated the two-byte string, leaving us
short some data.

Any articles you can point out would be helpful. We are very knowledgeable
inhouse on UNICODE , Single Byte and MultiByte issues involving C++, but
this is something we have not considered in the SQL Server/VB arena.

Thanks,

Michael

Michael J. Visintin

[BJ Freeman]

Here is what I do know from personal experience
1) there is a max for strings storage, Unicode cuts those in half.
2) all SQL should be put in the SQL server as stored procedures.(has nothing
to with Unicode)
3) in Stored procedures you can use convert to change.
4) you can change the NVARCHAR to VARCHAR and not have Unicode.
5) Unicode is only important if you are going to do Multilanguage's

"Michael Visintin" <Michael....@eaglepoint.com> wrote in message
news:uNwpW0#XCHA.2280@tkmsftngp10...