Since When

I found a URLEncode function for SQL Server on the Internet and promptly ported it down to my code base, however like some code I find on the Internet it wasn't very good, here is a suggestion for all of us posting code: include the test cases also -- sort of like Blog Unit testing. Anyways here is the problem simplfied in this example code: DECLARE @c char SET @c = 'é' SELECT CASE WHEN (@c LIKE '[a-z]') THEN 'Huh?' ELSE 'Better' END Know I know that é is not between a and z, however the output says it is. There is only 26 letters from a to z, at least that is what I am teaching my three year old daughter. So what gives, must be a SQL server bug right? Whoops. Checking the documentation for LIKE it appears that I was being a little small minded -- since only my native alphabeta has 26 letters between a-z, there are some alphabetas that have a few extra letters and my SQL server configuration is taking them into consideration. So what do I have to do to make this work -- COLLATE. Which really means tell SQL Server what language I would like to match against. This works better: DECLARE @c char SET @c = 'é' SELECT CASE WHEN (@c LIKE '[a-z]' COLLATE SQL_Latin1_General_CP437_BIN ) THEN 'Huh?' ELSE 'Better' END Now, back to URL encode, I would like URL encode to translate: é to %e9, so that I can get the URL with the name Café in them to appear correctly in XML. So why does é need to be encoded for the browser? Maybe it too is small minded. {6230289B-5BEE-409e-932A-2F01FA407A92}