Thx, that was consensus back then when I brought the idea up ;-)

It did sport a few other nuances like lazy decrypt via _ndecrypt field: if table was used in grid (_ndecrypt property on oca[Table]=[-1..-20] ), report (_ndecrypt property on oca[Table]=[-21..-40] ) or export (_ndecrypt property on oca[Table]=[-41..-60] ): decrypt whole table on getting data from backend, otherwise (_ndecrypt property on oca[Table]=[0] ) only if parent table record pointer was positioned explicitly to corresponding parent record via the special positioning methods on oca[Table]s base class: decrypt always set cursor.ndecrypt field to 1...

BIG project with enough slack to polish such nuances;-)

One of my knacks is dreaming up such schemes with valid gut estimates on reachable benefits in performance and implementing them in first draft architected (read encapsulated or isolated) at least well enough only minimal maintainance is needed [employing at least one big No-No in programming rules for the particular project for sure, but always documented as such up front].
Cynics might say others shun touching such project corners without studying the somewhat minimal code and [ahem] terse documentation and leave it running for many releases ;-))

>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.