>I'm converting a program originally written in Foxpro 2.5 for DOS into Visual Foxpro 6.0. One maddening idiosyncrosy I've encountered is the following:
>
>There are an encryption and decryption routines used for storing user passwords to a database. These routines work just fine in the DOS version. However when I use the IDENTICAL code in Visual Foxpro, I get erratic results. Occasionally, the encrypted password will decrypt just fine. But most of the time, at least one of the characters in the password will decrypt incorrectly. I have pulled these functions out of the program and run them independently of the larger program just to be sure there is nothing in the program which might be distorting this process.
>
>The encryption/decryption routine operate by the relatively common method of manipulating ASCII values via an algorythm. In DOS, everything works great, in Windows/Visual Foxpro, most of the time it doesn't. I have been unable to discern whether it is the encryption or decryption which is malfunctioning.
>
>Does Visual Foxpro/Windows handle ASCII values differently that DOS? If so, is there a Foxpro function which creates a compatibility between Windows and Foxpro ASCII handling?
>
>Confidentiality issues prevent me from posting the source code of these routines publicly, so I hope there is a generic answer which will rectify this idiosyncrosy.

Along with what Cetin said, you may need to mark the field where you store the encrypted value as binary (character or memo) if you're using Modify Structure, or as NOCPTRANS if you're creating the table in code. That way the values in those fields won't be interpreted through the table's codepage, but rather taken literally.

Another thing that may influence string comparison and manipulation is Set("Collate"). Make sure you set collate to machine on entry in your encryption/decryption code, and restore it on exit. Any other collate sequence can influence string comparison.