Duncan wrote: > On the collation end, we are looking over 18 languages, I think thats pretty > much any character under the sun. We have a db table, one column for each > language, so I am thinking I take Andy's suggestion and make the collation
18+ columns? i'm not sure that wide is the way to go but i guess db design styles have changed over the years. > on each individual column fit the language, rather than simply making them > UTF-8. Would this be a more effective use of SQL memory? sql collations have 3 parts: unicode, non-unicode & codepage for the non-unicode data. so you should certainly store your data as unicode (ucs2 NOT raw utf-8 like the bad old cf5 days, the JDBC driver will handle the conversion) using "N" datatypes but you can use whatever collation you want (this used to depend on what codepages were installed on the sql server, not true for win2k on). the default db collation should be the one that covers most of your languages. just an fyi, collation is a tricky business, there are sometimes more than one "commonly" used collation for a language (for instance german phonebook vs dictionary) so deciding which one to use (or is "more common") will require some research on your part--don't just pick the first one in the list ;-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:220100 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
