I would have to second JimWWinter suggestion about using some other means and Craigs Fll looks pretty good. About a year ago I started playing around with building my own class around the Crypto API functions and had some problems getting consistant results.
After posting a question to this forum Craig related his experience in finding a bug with the Cryptographic Service Provider layer in the Crypto API and suggested I look for other alternatives.
We have Cryptor (available through Hallogram) and its a good tool that can hook easily into a VFP app. What I wasn't comfortable with is that Cryptor uses a proprietary XOR algorithm that they give you little info about (at least at the time we purchased it). As Craig points out, that may not be good enough if you have a contract that stipulates a publicly recognized encryption algorith.
Our eventual approach was to build a C DLL around Bruce Schneier's Blowfish code. If that's not an option then I would definately look at Craig's Fll since he has already done it for you.
As for encrypting fields, It's seldom that the encrypted value is the same length as the plain text so you will need to convert every field to string and make them wider (at least as wide) than any encrypted value you would ever need.
You'll also need to consider the performance hit you'll take with encryted fields. While Blowfish is considered a fast stream cipher if you need to un-encrypted a cursor full of values it could slow things down more than you're willing to accept.
If you're looking for ease of use I would still recommend Cryptor as it's very easy to use and can make the encryption transparent to the user.
Keep in mind also that working on encrypted files, fields, etc makes things more difficult. I dread working on an app we sent out that uses encrypted tables as it always takes significantly longer to get it to a state where I can work on it, and then I have to convert it back.
Hope that helps a little bit.
Ralph Kolva