>>>>>I was asking if I should use nchar() vs. char() type, specifically. But I still would like to know a case of what value stored in the SQL Server tables char() type would cause a problem? and what kind of a problem?
>>>>
>>>>Again I would repeat varbinary(). Not char or nchar.
>>>>As I said before, your encryption result has non-printable characters.
>>>
>>>Do I understand that varbinary() would have to be mapped to char(binary) type field in VFP?. And I am not sure that it would work with cursor adapter via ODBC. Doesn't it requires either OleDb driver or Chen's updated VFP?
>>
>>Yes, varbinary maps to char (nocptrans), memo or (naturally) blob.
>>It does work with CA. I have no idea about Chen's VFP.
>
>I will test varbinary today. I think you use CA with OleDb (maybe I am mistaken) and I use it with ODBC. But it is worthwhile to test.
>
>I did another test since yesterday. I connected to 12 customers where the encrypted string (with all non-printable characters) is stored in a char(250) type field. Then, in every case, I tested getting all records for this table and converting them (in VFP) to a regular string. And not one case failed. That is, the SQL server has no problem storing these non-printable characters in the char(250) field. And my app has no problem retrieving them.
>
>I would like to test a case where it would fail but so far I cannot.

Store them however you like.