>>>>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Ð¥RÌ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?
"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