>>>>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.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham