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

As I'd previously noted, where you're likely to run into the problem is when you're dealing with different language settings (although I'd mainly focused on Asian languages, the problem could occur with European languages too). Basically you can observe behavior when you write binary data to CHAR fields with computer set to one language, then read it back out with computer set to a different language. The particular setting to change in Windows would be the language for non-Unicode applications. Although it's probably not likely someone will keep switching languages on their computer, it isn't an unlikely situation where there may have a variety of different language configurations within a business (especially if they work internationally).
As I'd previously mentioned, my first experience with the headaches in character set translation was at university when transferring files between IBM mainframe/minicomputer using EBCDIC and others using a variation of ASCII. The alphabetic and digits would typically be OK, as were the more common punctuation used in English. Characters like curly brackets, caret, backslash, vertical bar, tilde, and square brackets would sometimes get mangled, as well as handing of horizontal tab was frequently inconsistent (the mangling usually meant transferring C code especially problematic -- the workaround for me was to replace many of the problematic characters with their trigraph equivalents). And if you were transferring binary data, you needed to make sure you've specified appropriate flags so that character set translation didn't occur. Another hazard of transferring text file (even between different systems using ASCII) was the representation of newlines (sometimes it's carriage return followed by linefeed, in other situations it's just a linefeed, and a few others simply a carriage return, and have run into rare occasion where it was linefeed followed by carriage return).