>Cetin:
>
>I see what you are saying about bypassing the stored procedures for an average vfp guy. i saw the following at another website (foxite) that was talking about the firing of dbc_opendata:
>
> If you have VFP you can stop this code from firing by opening the DBC as a DBF with the USE database.dbc, this then opens the DBC as a table, you can then change the stored procedure code and recompile the database with COMPILE DATABASE
>
>I was hoping for a bit more security than this. For example, we deal with sensitive information on our tables and should our server be stolen (a possibility), I at the least want the information to be difficult to get to, and at the most to be simply encrypted. Maybe VFP 8.0 doesn't offer this?
>
>I looked at the _cryptapi example in the solutions with VFP8.0, and I have played around on this a little, but my knowledge of foxpro isn't good enough to have a thorough understanding of if this can take me where i want to go. Do you think that this sample is worthwhile looking into for me.
>
>Paul

Paul,
With _cryptapi it might be harder plus _cryptapi doesn't have the same consistent behavior on different OS (on XP I saw it fail often - might be fixed but once I had the bad impression on its reliability I didn't check back again).
Then what about not using native VFP tables but MSDE. It's free limited SQL server. With VFP8 using it via CursorAdapter (as an addition to SPT and RV) makes it easy to deal with for a VFP user. Once the server is stolen (hope never happens) it's easy to crack into admin password so I'd add a second barrier making MSDE instance to have SQL login (windows account, SQL login or mix mode it uses - with mix mode or windows account once you log on to windows with admin account you've access to MSDE. Having only SQL login you add one more PW to crack plus data files are encrypted hard enough to crack for more than average user).
Cetin