Storing Chinese, Japanese and Korean is not just simple Nvarchar issue because all three languages alphabet is more than 2000 characters so SQL_Variant is rolling the dice that you will not run into character conversion issues. The reason there are more one than one Chinese and Japanese collation defined in SQL Server 2005. When you accept langauge specific content there is no extra code needed, just use VS2005 to save your code for each langauge and use the langauge packs for .NET Framework. I have worked in more than 20 languages application and a friend run a 32 languages application. When you are not using the 26 character Latin alphabet things can get very complicated.