>>>>>>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.

I sense frustration in your voice/writing. I am not arguing with you; I am just trying to find a condition when storing the string with un-printable characters in a Char type field fails. It could be a certain setting of the SQL Server; which I am willing to duplicate. Once I know that there is a potential problem (that I can duplicate), I can plan an alternative approach. And I am going to test the varbinary with the ODBC but not sure if it will work.