>>>>>>Hi,
>>>>>>
>>>>>>I am using cipher() function to encrypt a long string (250 char). Then I need to store the encrypted value into a field of a SQL Server table. Can the field be type CHAR(250)? or it must be NCHAR(250)?
>>>>>>
>>>>>>TIA
>>>>>
>>>>>I would ditto on Naomi, it should be binary, unless you also convert it to base64 encoded value. Otherwise, you are in danger of losing data, be it char or nchar. BTW cipher() function, what is that? I only assumed it was something doing encryption using one the known algorithms.
>>>>
>>>>Yes, cipher() is a function that does encryption. Sergey Berezniker converted it from C to VFP some many years ago. I don't know who wrote the original (C-version) of this function.
>>>
>>>Is that a special encryption algorithm that never return non-printable characters and also with an exact size? If so you can use char(N). nchar() uses unicode.
>>>
>>>If it might return a non-printable character and size is not fixed (both case are the usual cases with encryption algorithms) then varbinary(N) or varbinary(MAX) is the choice. You might instead use varchar(Max), provided you are converting the value to base64 encoded - StrConv(encrypted, 13).
>>
>>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\
>>

>
>I see accented characters in there -- these would lie outside the normal printable range (code 32 - 126). Such characters outside this range can get remapped to other characters when transitioning between codepages -- so there's a possibility that you might write one thing, but what gets stored is turned into something else (so when you read it back, you might not get back what you wrote). Basically some characters may exist in one codepage but not in another -- so translation could result in loss of some characters. Another problem would be that some characters in one codepage would be at a certain code value, but a different one in another. If you insist on using a CHAR field, then I would recommend that you store base64 encoded version into the table rather than the raw binary one. Base64 encoding will result in a slightly longer string that only consists of characters in the set ['A'..'Z','a'..'z',' 0'..'9', '+', '/','='] -- which generally exist in most computer character sets and thus aren't subject to being transformed into a completely different character when switching between encodings. To get back the original value, you run the base64 encoded string through the reverse transform.

How do you convert a VFP string to a base64 encoded version?