OK, now I understand the difference between ntext/nchar/nvarchar and text/char/varchar, and some details surrounding it that I did not know about.
But still, I can not find a solution for my problem.
After your writing, I changed the column 'parbody' (see example above) to 'text' instead of 'ntext'.
But the euro symbol is still converted to a question mark by sql server.
The database properties indicate that the 'Collation name' is 'Latin1_General_CI_AS'.
Actually, I don't know exactly what that is, other then that the page encoding for my web pages is iso-8859-1, which is also called 'Latin1'.
Any ideas?
All I want to do is put some text, encoded as iso-8859-1, in a sql server database, with coldfusion. (without having to write a 'N' before every string).
Main Topics
Browse All Topics





by: pinaldavePosted on 2004-12-28 at 08:40:42ID: 12913221
Hi Paulio,
/features/ mssql/arti cle.php/ 14 42341#part _10
Traditional non-Unicode data types in Microsoft® SQL Server™ 2000 allow the use of characters that are defined by a particular character set. A character set is chosen during SQL Server Setup and cannot be changed. Using Unicode data types, a column can store any character defined by the Unicode Standard, which includes all of the characters defined in the various character sets. Unicode data types take twice as much storage space as non-Unicode data types.
Unicode data is stored using the nchar, nvarchar, and ntext data types in SQL Server. Use these data types for columns that store characters from more than one character set. Use nvarchar when a column's entries vary in the number of Unicode characters (up to 4,000) they contain. Use nchar when every entry for a column has the same fixed length (up to 4,000 Unicode characters). Use ntext when any entry for a column is longer than 4,000 Unicode characters.
Note The SQL Server Unicode data types are based on the National Character data types in the SQL-92 standard. SQL-92 uses the prefix character n to identify these data types and values.
Also
Please refer : http://databasejournal.com
Regards,
---Pinal