Printable View
Hey, what is the difference between the two ?
Cuz i had a problem :
http://www.vbforums.com/showthread.p...hreadid=185034
And now when i switch nVarChar to varChar, it works !!
Weird, but i want to know if it will affect something if i chage them all to
varChar!
tx
dear sebs,
nvarchar is for unicode characters, varchar is not
help says:
nchar and nvarchar
Character data types that are either fixed-length (nchar) or variable-length (nvarchar) Unicode data and use the UNICODE UCS-2 character set.
nchar(n)
Fixed-length Unicode character data of n characters. n must be a value from 1 through 4,000. Storage size is two times n bytes. The SQL-92 synonyms for nchar are national char and national character.
nvarchar(n)
Variable-length Unicode character data of n characters. n must be a value from 1 through 4,000. Storage size, in bytes, is two times the number of characters entered. The data entered can be 0 characters in length. The SQL-92 synonyms for nvarchar are national char varying and national character varying.
Remarks
When n is not specified in a data definition or variable declaration statement, the default length is 1. When n is not specified with the CAST function, the default length is 30.
Use nchar when the data entries in a column are expected to be consistently close to the same size.
Use nvarchar when the data entries in a column are expected to vary considerably in size.
Objects using nchar or nvarchar are assigned the default collation of the database, unless a specific collation is assigned using the COLLATE clause.
SET ANSI_PADDING OFF does not apply to nchar or nvarchar. SET ANSI_PADDING is always ON for nchar and nvarchar.
kind regards,
big nell
cool, tx a lot man!
so all the field thqat start with n, it's for unicode!
so that why the mail merge was'nt working!
tx again man!
pardon my ignorance, what is unicode?
(I have the same dissapearing fields problem, when it was an access database the fields were 'memo' but when I converted to ms sql i set them as varchar (or nvarchar, cannot remember) but from time to time I call the data but it never appears.)
Thanks,
Michael
unicode is those extra sign that are not in the ascii table!
you know when you open a file in notepad and you see
little black square, well those are unicode, since notepad
does'nt support unicode, it show black square!
dear michael,Quote:
Originally posted by msimmons
pardon my ignorance, what is unicode?
(I have the same dissapearing fields problem, when it was an access database the fields were 'memo' but when I converted to ms sql i set them as varchar (or nvarchar, cannot remember) but from time to time I call the data but it never appears.)
Thanks,
Michael
unicode character sets are created to support language specific characters (german umlauts, czech hadjek, and so)
unicode characters are composed by two bytes instead of one in e.g. ascii
help says:
Using Unicode Data
The Unicode specification defines a single encoding scheme for most characters widely used in businesses around the world. All computers consistently translate the bit patterns in Unicode data into characters using the single Unicode specification. This ensures that the same bit pattern is always converted to the same character on all computers. Data can be freely transferred from one database or computer to another without concern that the receiving system will translate the bit patterns into characters incorrectly.
One problem with data types that use 1 byte to encode each character is that the data type can only represent 256 different characters. This forces multiple encoding specifications (or code pages) for different alphabets such as European alphabets, which are relatively small. It is also impossible to handle systems such as the Japanese Kanji or Korean Hangul alphabets that have thousands of characters.
Each Microsoft® SQL Server™ collation has a code page that defines what patterns of bits represent each character in char, varchar, and text values. Individual columns and character constants can be assigned a different code page. Client computers use the code page associated with the operating system locale to interpret character bit patterns. There are many different code pages. Some characters appear on some code pages, but not on others. Some characters are defined with one bit pattern on some code pages, and with a different bit pattern on other code pages. When you build international systems that must handle different languages, it becomes difficult to pick code pages for all the computers that meet the language requirements of multiple countries. It is also difficult to ensure that every computer performs the correct translations when interfacing with a system using a different code page.
The Unicode specification addresses this problem by using 2 bytes to encode each character. There are enough different patterns (65,536) in 2 bytes for a single specification covering the most common business languages. Because all Unicode systems consistently use the same bit patterns to represent all characters, there is no problem with characters being converted incorrectly when moving from one system to another. You can minimize character conversion issues by using Unicode data types throughout your system.
In Microsoft SQL Server, these data types support Unicode data:
nchar
nvarchar
ntext
Note The n prefix for these data types comes from the SQL-92 standard for National (Unicode) data types.
Use of nchar, nvarchar, and ntext is the same as char, varchar, and text, respectively, except that:
Unicode supports a wider range of characters.
More space is needed to store Unicode characters.
The maximum size of nchar and nvarchar columns is 4,000 characters, not 8,000 characters like char and varchar.
Unicode constants are specified with a leading N: N'A Unicode string'.
All Unicode data uses the same Unicode code page. Collations do not control the code page used for Unicode columns, only attributes such as comparison rules and case sensitivity.
/*end help*/
hope this information is of use for you,
big nell