>>
>>Nicely fleshed out :) Very good point about decrypting/encrypting on export/import.
>
>To me the decrypting/encrypting on export/import won't be a problem. Here is why:
>I plan to store the undecrypted string of "Y" and "N" in this table anyways (in a separate field BACKUP_STR char(250), along with the encrypted one. So, if there is a case of export/import, I will have a separate routine that will encrypt the string based on the new PK.
>Some will ask, why encrypting if you show the entire string undecrypted. It is ok if a user know that he or she cannot get access to feature A (based on the undecrypted string). They won't be able to change it since the VFP 9 application will only use the encrypted field, when a user logs in.

Ahem... You missed the boat. By miles.
Keeping such duplicate/dependant data is also going smack against normalization rules - without the sometimes true observation, that in some cases denormalization can avoid costly joins. Not true for such a function call, if function is optimized.

If you are CERTAIN that your backend is secure, create getter/setter? functions for the field and forget keeping the encrypted record in the table.

Yes, CPU will be utilized a bit, but current CPUs are STRONG. Also, there are lots of ways to lessen the task for the CPU.

The question of the post is basically already misleading: If you want to efficiently encrypt a long sequence of binary options, first order of business is to forget ["Y","N"] encoding and move to more efficient bit-mangling.

If you do not want the user to see the options, do not publish them, keep them on your server: no need for .encryption or obfuscation, keep it purely server-side same as surrogate PKs (yes, I remember you publish those as well...).

If you only want to obfuscate, easier steps are available: for instance switch the binary decision to the difference between upper() ad lower(), but encode each decision with a randomized letter: for instance ["DmiTry"] would be TffTff, same as ["DraGan"].
The space WASTED by keeping datatype Char would at least be minimally utilized. From encryption POV kindergarten level if one really tries hacking.

If my tone in this post reads harsher then typical even for this German, take it as a friendly rap on the head to question your basic assumptions on data/function type, developer and user needs as well as data design.

;-)

//upd:
If "bit-mangling" is too cryptic, it is the same idea Antonio offers you.
If your head really is bowed, just shove some text on bitwise encoding half a meter under it. Help of vfp on BitClear(), BitSet() and BitTest() should propel you to more than a running start: hold your head up soon afterward, so you see where you are running to
;-)))