>>>>>>>>How do you convert a VFP string to a base64 encoded version?
>>>>>>
>>>>>>You might consider saving time and $ by simply using VFP's STRCONV with nConversionsetting =16, then 15 to restore. One line of code, no other dependencies.
>>>>>
>>>>>I will consider it.
>>>>>
>>>>>What is strange (to me) is that despite the insistence of gurus here that non-printable characters cannot be saved into a Char() field of SQL Server, I have not came across a problem. I have a number of customers who store my encrypted string (with many unprintable characters) in the Char(250) field and I have not seen one issue.
>>>>>What I will do is connect to all of these customers and do another test. Simple get the value stored in the Char(250) from SQL Server (with many if not all unprintable characters), then on the VFP side run them through the cipher() function and see the results.
>>>>
>>>>One problem is that behavior of storing character codes 0-31, 127-255 may not always yield predictable results (especially when you're dealing with different character sets on different computers). Character codes 0-31 and 127 in ASCII are used for control information, and some like 13 (carriage return) and 10 (line feed) are used differently by different systems (notably in how "newline" is represented. In DOS/Windows typically "newline" is carriage return followed by newline. Under Unix "newline" is simply linefeed character. Other systems may use carriage return for indicating newline). Character codes 128-255 are often interpreted differently depending on context. For example in context where Chinese, Japanese and Korean language are involved this range is typically used in double-byte systems to represent the additional thousands of characters required for these languages (and if that's not bad enough, *each* of these languages have at lest three or four variations that are *incompatible* with each other).
>>>>On the topic of dangers of character codes in the 127-255 range -- in VFP you generally want to avoid string literals containing these (e.g. things like "this" or 'this' or [this]) containing character codes in the range 127-255 in your code -- especially in the case where they might be used in Chinese, Japanese or Korean language environments. You could have a program that works perfectly well in English language that will often crash with runtime errors when run in Chinese, Japanese and Korean language environments. On the other hand, if you use expressions like CHR(nnn) you're generally OK as far as avoiding those weird crashes (as for how those characters get interpreted as output is a different story).
>>>
>>>>>You could have a program that works perfectly well in English language that will often crash with runtime >>errors when run in Chinese, Japanese and Korean language environments.
>>>I can live with the above limitations :)
>>>Thank you.
>>
>>You say that now, but who knows what the future may bring? Better to know about things to watch out for, than to be completely without a clue if and when the problem occurs. Not fun when you have this happen on a *live* system.
>
>I hear you. I am trying to do the best I can without killing myself in the process. Because I am not around, it does not matter how perfect is my code. You know what I mean? :)

Having to fix a mess left by someone isn't fun. Less fun is when that someone was yourself. And definitely an awkward situation when you come to the realization that the person you've been badmouthing for leaving the mess is yourself. And definitely an uncomfortable situation if your client figures it out too.