>>>>>I see, I would never use that as an "encryption" for myself.
>>>>
>>>>Why not?
>>>
>>>Seed is derived from the string itself. This means the string will always be encrypted the same way. You need an external seed independent from the string. Most people use the pk or timestamp of the record where the string is saved.
>>
>>I actually do use a seed based on the PK value with additional "twist". So that even if someone has the table and knows the PK value, they would have to figure my "twist". And if they do, they deserve to have the data :)
>
>Well that changes matters. Without that, I have agreed with Cetin.

My main concern now is where to store the encrypted field. Binary does not seem to be the option since, as John Ryan said, it could be a problem for the ODBC driver. And I am not about to update my app to Chen's version or change how the app connects to the SQL Server. You mentioned that you store your encrypted string in a char type field. And I trust that you would have changed the type to nchar if you ran into an issue.
Changing from char to nchar seems to be the easiest approach to prevent the case (if possible) that the cipher() creates a character that conflicts with char field in SQL Server.
Again, security of my encrypted string is the least I worry about.