>>>>Tore is not quite correct - DBF files can be protected but .... First, Cryptor is a discontinued product but does work under all versions of Windows including under 32 bit and 64 bit versions. The problem is that it is discontinued. There is another product found at the link below that will encrypt all or some of your files but allow your application to read-from and write-to them seamlessly from within your application. However, with any technology like this the security problem then moves up the line to needing to protect the password stored in the VFP application itself. If I can hack the VFP EXE and extract the password then I can access the encrypted database. Therefore I need to also protect the EXE file as best as I can. There are several options, all eventually crackable, but at least it's better than nothing. See this link for seamless file based encryption from within VFP or any other programming language that supports ActiveX / COM ... not cheap ... I guess it depends on how valuable your data is to you.
>>>>
>>>>http://www.netlib.com/file-encryption.asp
>>>
>>>Cyanide is quicker.
>>
>>A strange comment which I don't really understand. Within a few minutes he can encrypt his files, add in the DLL, make a call to the DLL, and have seamless on-the-fly encryption/decryption in his VFP app. What do you find hard about that for a developer with an existing VFP application using DBF files and needing an encryption solution? Do you think converting that application to SQL Server is a simpler solution? Just rhetorical questions.
>
>I was referring to my earlier message that DBFs are not secure. You can do tricks to work around any problem, but trying to make a DBF secure is like converting a bicycle into a car. Why bother, when there are far better solutions. Especially now that DBFs will die sooner or later, I assert that using a "real" database server for storage is the best way to go.

Tore,

you technically quite correct that an encrypted local/client side dbf is still not a watertight system if accessed via local fox exe - I have raised that point myself often enough. OTOH for some scenarios (road warrior without guaranteed net connection) the alternative is in reality not much safer (as it shares the vulnerabilities of the base vfp exe, the "secure" local SQL server can be queried from inside the exe in a debug, suspended session or dynamically added script) and even a server database can be read from a cracked client side vfp exe and the query results can be easily piped into dbf, csv or other wanted format.

Going the extra mile for a local database - indispensable for such scenarios as described above - IMHO via dbf encrypt OR local SQL server install is misguided. Use the security or encryption options of the OS, as no cost is added and the risc is similar in all alternatives.

If only SOME/FEW tables need to be encrypted IMO it might be argued that dbf-encryption is a better alternative IF IT FITS the overall dir/app layout. Even here for new stuff I'd prefer a 2-dir approach - encrypted via OS vs. open.

my 0.01€

thomas