>>>>>>I don't know the answers to these questions. Here is an example of the encrypted string:
>>>>>>

>>>>>>xvneoUNC7ùêæĵ˜†]T>"Ûͪ“m|+ 缨pMöûžjBÓ±zIǼw9öŒKÐ¥Ȑw
¾q)ЗOý²PÇlûtÊs)¿f¯|ï•-ÎX§8ÖJ‰;Çgé| ™µEÏVîfëpíX‘‡3ø{÷\ç[ÕHð4­ˆËhÒ@³+…èW¿‡ïO¬>nË(ŠÕ>œòK‘õLŠäg„ð$kúe¿ç‚ÕM£Ä
Q†éT–¸Õ*rƒßØ's¯¯s"Í–ŸsSÖÂ¥‚bq"êÏ㻆iwp-=ÔôÃج“¸´Šƒ«—–mo\
>>>>>>

>>>>>
>>>>>With this value, your best bet is varbinary(). It contains non-printable characters (and also length is 251 for this sample).
>>>>>
>>>>>I would use varbinary(MAX) but you can choose an arbitrary max length like varbinary(8000).
>>>>
>>>>Currently I store the above (and similar strings) in a char(250) type field. About 20 users and they have no problems.
>>>>
>>>>Aside from the varbinary(), what specific issue I may have with the above type string in a char(250) type?
>>>
>>>You were asking about storing in MS SQL Server, no? In VFP, you can store any character's value including the chr(0) in a char field. However, in MS SQL it is not the case. You might have values, that doesn't cause any problems, but sooner or later a value would show the problem. Why are you resisting to storing in a varbinary field, I don't understand. If you wouldn't store in a varbinary, then at least convert the result to base64 encoded value and store in a varchar field.
>>
>>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?
>
>CHAR in Code 1250 not is CHAR in codepage 1252.
>In VFP you can use NOCPTRANS. MSSQL has not equal option.
>BINARY(n) or VARBINARY(n) is safety.
>
>MartinaJ

Thank you for technical input. I don't know how the Cipher encodes a string, so I don't know if it is possible that a CHAR in Code 1250 is possible.