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.

>Thanks Al. I am a long way along in the process. We first encrypted all character fields that contained sensitive data ("personally identifiable information") and now we are moving on to numeric data - so that no one could figure out that you have a bazillion dollars in your bank account.
>
>Somewhat leery of 3rd party products unless they come with source code and use some Windows function to achieve the result - don't want to get bit by someone retiring and then the product goes dead and the customer is stuck. Or at least, in one case, using Rick Strahl's products as he seems to be sticking around and looks young :-) So at least he should not retire until longer after I am gone.
>
>I suspect that within a few years this app will be rewritten and moved into SQL server and it has built in column level encryption - at that point, I will be decrypting all their data and uploading it to something new!
>
>Albert
>
>>>Hi all,
>>>
>>>Have been encrypting some fields from some sensitive tables in an app. The app uses local views and the ones that have encrypted fields are created programmatically. The fields that are character fields are easy - extend the field to handle the increased size of the encrypted data and then decrypt on the fly and encrypt during the save process of the form.
>>>
>>>I have written a wrapper function to make decryption really easy to incorporate into SQL strings e.g.
>>>
>>>CREATE SQL VIEW v_Lawyers AS ;
>>> SELECT Lastname, Firstname, ;
>>> DecryptString(DirectLine) AS DirectLine...FROM Lawyers...
>>>
>>>So for the character fields, the field gets decrypted in the above view, bound to the form control and then just before tableupdating the view, the pertinent fields are encrypted.
>>>
>>>BUT, this does not work well for non-character data. For example, for birth dates I have to pull out the data using a function that converts the character encrypted date into a date field:
>>>
>>>CREATE SQL VIEW v_Plaintiffs AS ;
>>> SELECT Lastname, Firstname, Gender, ;
>>> MakeDecryptedDate(Birthdate) AS Birthdate2, Birthdate FROM Plaintiffs...
>>>
>>>So in this case, I bind to "Birthdate2" as it is in date format and carry along Birthdate which is the original unencrypted character type data. The user updates Birthdate2 and then in my save routine, I encrypt the data in Birthdate2 and overwrite Birthdate and post.
>>>
>>>Okay, so having said all that - are there any other ways someone can think of that would make this easier? I am at the point in the project where I have to start encrypting a whole bunch of numeric type data and I will have to go through the same gymnastics on each of those fields.
>>>
>>>BTW, this would have been transparent in the latest SQL server (I hear) where the back-end engine handles all the encrypting/decrypting - but that is not even a possibility at this point for this client.
>>
>>Somewhat off topic, but have you evaluated any encryption products for VFP?
>>
>>One that I understand has been around for a long time is NetLib: https://netlibsecurity.com/products/encryption-desktops/ . The site claims there's a free evaluation.
>>
>>It was recommended at one point by Microsoft: https://support.microsoft.com/en-nz/help/115476/how-to-encrypt-visual-foxpro-dbf-files
>>
>>From what I recall many years ago NetLib isn't cheap. But you may find it easier and more comprehensive than rolling your own.