Thanks Paul. The cfsqlparam thing seems to have done the trick. 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 on each individual column fit the language, rather than simply making them UTF-8. Would this be a more effective use of SQL memory?
On 10/5/05, Paul Hastings <[EMAIL PROTECTED]> wrote: > > Duncan wrote: > > The only way we can get the chars to display correctly is by entering > them > > in to SQL Server 2000 using th N'string in here' notation. But that > means > > no, you could & should use cfqueryparam along with turning on the > unicode option for that DSN. here's a blog entry on the subject: > > http://www.sustainablegis.com/blog/cfg11n/index.cfm?mode=entry&entry=F9553D86-20ED-7DEE-2A913AFD8651643F > > > > the db collation is SQL_Latin_General at the moment - I have a bad > feeling > > this is the problem and its not easy to change? > > that would depend on if the chars you're looking for are in that code > page. even w/unicode, you want to use collations that cover the majority > of your user's languages. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:220083 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
