I agree with all that.
Keep in mind too that encrypting the schema is no different from encrypting the actual data. If by schema you mean the names of the fields, their data types and their sizes, that information is clearly visible in the header of the DBF. A knowledgeable user would only have to open the DBF in a text editor in order to read that information.
And, by the way, the fact that you were previously storing your data "in the cloud" (whatever that means) doesn't make any difference. The point is that, at some point, your application had to download the data to the local machine, at which point it would have become visible a (knowledgeable) local user.
I suggest you've got three options:
1. Encrypt the entire DBFs. That would include the schemas and the actual data. You can do that with a commercial encryption utility, or you can write your own encryption program (perhaps using _crypt.vcx). But sooner or later the files have to be decrypted, at which point they become vulnerable (not to mention adding quite a lot of overhead to your running times).
2. As the others have suggested, move to a secure SQL back-end. If you are really worried about users looking at your schema and/or data outside your app, that is definitely the best option. But be aware that migrating to a different back-end will take a great deal of work and might mean you having to make some fundamental changes in the design of your app.
3. Do nothing. Ask yourself what the cost is of someone knowing the structure of your tables? Does it really matter if they discover your field names and data types? Is there some specific threat that you feel you are exposed to?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads