Cryptor keeps people from finding out the contents but not from wipping out the data.

The issue is that in order for a data entry clerk to put data into a DBF over a network they need read/write privileges. At least every VFP accounting system I've ever set up does it that way. While you may only want the user to be able to enter data, write to one or two particular fields, or just view a limited set of records... the read/write privliges apply to the whole table. So with or without Cryptor doing a USE table followed by replace all (field) with "" and you are done.

Many malicious attacks are not just about keeping data from prying eyes but keeping data from being wipped out entirely.

Also you can't delete SQL Server anything if you use SQL Server authentication and never give users any NT authentications to the server. There is a huge difference here. I can specify in SQL Server what data access the user has without giving them any privliges to the NT system that would allow a user to destroy data through the Windows file system.

Now it's possible a user could hijack the ODBC connection outside of a VFP app which is why it's important to lock down user options in SQL Server and keep the password encrypted in the VFP EXE. Never do I put a password in a workstation ODBC and I always try to use DNSless connections to further conceal the server logons from the average hacker.

VFP is a good database and I think many people under-estimate how valueable the VFP engine is in client/server apps. But when you start getting into heavy duty security it's hard to protect VFP if someone is determined to mess you up.

Greg

>Greg
>
>While we put all of our data in C/S databases... I'm not sure I agree entirely with the security issue. Have you heard of cryptor? Look at www.xitech-europe.co.uk ... you can still delete the dbfs if privs are set wrong, as you can with a SQL server database, but you can't misuse data or wreck it.
>
>I agree with the risk of flicking off computers, though. We had a customer whose typists found that flicking their computers off and on caused documents to print faster- some network glitch that caused a complete network walk every time they printed- so they did it every second or third transaction.
>
>Regards
>
>j.R