A Global Reach
-
Looks like I'm a real minority... US English only but using Unicode. Our company's products all deal with management of medical research studies which includes writeups of the science involved. As a commercial product we need to allow for use of the extended character sets in all our text fields thus driving the use of Unicode.
Regards,
Greg Young
-
I went and wrote up a few paragraphs about Japanese but then it didn't post? When I clicked 'post' it just cleared the text box!
-
Jasmine, I've had that same problem on this forum. I always copy each post in case that happens. I just paste it back and re-post. I happen when someone gets a reply posted before you. At least I think that this is what causes it.
ATBCharles Kincaid
-
New Zealand has two legal languages - English and Maori. The only "special" character in Maori is the little bar that can be placed over a vowel. It indicates that the vowel should be lengthened when spoken. Some text simply doubles the vowel - but a macron is the prefered representation. It's not trivial to deal with this small number of non-ANSI characters. Our new SQL Server databases are generally using nvarchars for all names. Names covers a broad range - but essentially it's any words that could include macrons. From a database perspective problems arise when data has to be replicated into older databases, or into new ones that either forgot about macrons or didn't know unicode existed. From an application perspective I think the biggest problem is that not many business analysts or testers consider unicode. Many users of applications wouldn't know how to enter a macronised character into a string.
While New Zealand has only two legal languages, we are very much a multicultural society. We can treat each macronised character as a special case when we have to deal with non-unicode applications and databases - but a much bigger problem when we've allowed unicode is the question of where to stop? Do we allow any unicode character, or only a subset? Essentially this would consist of ony characters which are based around ANSI. Or, to put it another way, only those characters that an English speaker could make an attempt at pronouncing.
-
I never seen any application or database supporting languages other than US English throuhout my professional career span of 5 years. The reason for this in my opinion is that in our country most of the pepole using PC's are litrate and they have some know how of English. Therefore companies developing business solutions did not have any interest in developing applications other than English. Which I think is not good. Companies should provide solutions supporting local language so that most of the population can be banifitted from it. Even illitrate people can get into the fast movining streem of knowledge world.
-
(Our multi-ligual is English and Spanish. The reason all of our fields are nvarchar is that varchar is NOT SUPPORTED on the mobile.)
The .NET Char is Unicode by default so the database Char/Varchar up to 250 is bytes in .NET, so using NVarchar makes it easier to bridge the gap.
(It's been a long road (about 6 years since I first started this journey) but we are finally starting to realize the significant benefits of this path. What's funny is that our Oracle team is miles (or kilometers) behind us...HAHAHAHA!)
Oracle is trying to support both UTF8 and UTF16, SQL Server just support UCS-2 a version of UTF16 which makes it easy to use.
Kind regards,
Gift Peddie -
I've seen companies in the UK and South Africa code nvarchar and ntext variables just for the sake of it, without thinking why, and without any need for them. It doubles your storage, and can mess up use of indexes (or so I've heard). I think a lot fo education is lacking. One dev was designing a database, and I noticed she was using nvarchar. I asked why, and she didn't know. Using varchar would have had no adverse impact on her system, as it was a single language system.
And the bit about the dates drives me crazy. We use a localised version of SQL for the dev boxes, with British English as the default and using dd/mm/yyyy. When we use our live boxes, we log into our offsite data farm; and their servers are set to mm/dd/yy. Suddenly our dates don't work anymore, and the code breaks or does very nasty things.
-
Sigh, lost my post again
Just as well this time I saved the text to an editor. Perhaps there should be a warning on the "Your reply" box that you should not click the Preview or Post Reply buttons without saving your post externally first?Hello Waye - one reason why you are much more likely to see developers using nvarchar is because it is now used within Microsoft samples, including the SQL 2005 AdventureWorks databases. I think this is a very good thing. We should be using unicode wherever a name is being stored (person name, street name, country name etc). But we also need to think carefully about the consequences of doing so.
As for dates, I assume you're talking about an application not working. It's very important to store and pass dates/times in unambiguous formats. If you're going to store a date in a char, use a format like yyyymmdd or dd-mmm-yyyy. Presentation (and entry) can then be changed to suit the user's locale.
I noticed something interesting about my earlier post. I went to the trouble of using the html-view to insert macronised characters within my post (e.g. as ā). They showed up in the "design" view before I saved my post, but aren't visible now. Just out of curiosity, I'll put some macronised vowels here: aeiou. A clear case for this forum to use unicode?
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply