Well, that's an interesting concept and definitely would be easier. What do you do though for running reports against the data - you would have to decrypt the entire table into a temp table and then run your queries against it - if I understand your structure correctly.

>In the first iteration we did the same.
>As more fields had to be encrypted and bulk operations and printing were happening often, we went to a different logic: all tables only have 1 encrypted field (can be memo) which gets decrypted into a blank 1:1 related table (or scatter name object). Encrypt/decrypt is done via handcrafted Fll according to the empty table structure bound by name convention to data table in the DBC. As there is only 1 crypt string per table should be more secure.