October 23, 2004 at 9:35 am
hey all,
i would like to know what for the following datatypes are used?please explain me!
a)TimeStamp
b)nvarchar
c)image
d)what is the difference between varchar and nvarchar
thanx for all ur help!
Rajiv.
October 25, 2004 at 9:22 am
timestamp - used to version stamp table rows. It is automatically incremented every time the row is modified
nvarchar - used for variable character data that will translate to the same characters on any computer, no matter what collation they use
image - used for variable length data greater than 8kb or images (GIF,JPG,etc.)
difference between varchar & nvarchar - nvarchar uses 2 bytes for each character rather than 1; maximum size of nvarchar is 4000 character rather than 8000; use nvarchar for systems that must handle different languages
There's a lot more detail in Books Online, if you have access to that.
Greg
Greg
October 26, 2004 at 11:10 am
hey greg
thanx for ur help man. but nvarchar still iam confused and u have touched upon a term "collation" could u be able to tell me what is collation. thanx.
Rajiv.
October 26, 2004 at 3:29 pm
Here's a quote from Books OnLine:
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/regions. 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.
Greg
October 29, 2004 at 12:59 pm
hey charles thanx for ur efforts and help
Rajiv.
November 10, 2004 at 1:51 pm
Varchar and NVarchar handle the same types of data (characters that will vary in length). Varchar is used for applications that are used in the United States and most European countries. NVarchar is for UNICODE - which allows more characters. You would use UNICODE for applications that keep Japanese or Chinese characters, for example.
Quand on parle du loup, on en voit la queue
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply