>SNIP
>>I agree that there are probably very few VFP developers that are actively trying to secure their data. Is this because there is little need, because it is too much effort or some other reason - perhaps we need another survey!
>
>Hmmmmmmmmmm, given the number of VFP apps written by other developers that I have been asked to modify or upgrade and the little security employed in them (on all Os's) I'd have to agree... but then, it is about equal to the Access apps (can we really call them apps?:O) I've looked at which typically are designed worse than VFP apps and their newer to boot...

I agree with both of you, having not only seen non-existent security waaayyy too many times in parts of my agency, but perhaps worse, I've done my own share of lax security setups, back in the early days (though to be accurate, security was not a real high concern to most people 10-15 years ago in a network environment). Like pluggable server drives sitting out in the middle of the floor in a busy & insecure work area :-)

I've seen bad security everywhere, though. There's no restrictions on which products can be found with terrible security, including server DBs as much as anything. Pretty much everything relies on humans, who tend to err a lot...

I think the fundamenetal point here is that one can achieve security almost as good, or even just as good, with vfp apps & data as with anything else - it's mainly that you have to go through some contortions to accomplish it with vfp data. I have the "benefit" (sometimes it's nice, sometimes a royal PITA) of DOD C2 security - but this does help to make beefing up vfp security simpler.

Like Houston, I have my own vfp-data security setup, and it's *tight* - tighter than some of our Sybase/Oracle systems, from my snooping around other servers at my workplace. My vfp setup also protects extremely well against corruption, and handles hundreds of multi-users just fine with very large data (okay, "fairly large" - the largest system ranges from about 10-15 GBs).

However, it has been no small task to plan, set this all up, and maintain it with rather frequent user-turnover. Lots of time spent maintaining domain groups, folder permissions, dividing data into smaller DBCs/tables so only certain users have any access, then merging tables off-line, etc. The default is everyone except 2 DBAs are locked out of everything, and users are only allowed "small slivers" of data-access as truly needed and verified. So, a user having vfp (or Access , Excel, etc.) on a workstation will not get the user much of any data access in my configurations.

Keeping all possible DBCs, tables, & indexes readonly to almost all users almost all the time will eliminate pretty much all corruption problems, I can guarantee anyone. It's a bit of a pain to set up, but it does remove corruption. (Keeping just the DBCs in separate readonly folders, though, is simple, and has enormous data-stability benefits. I recommend this policy to everyone, where possible.)

So there's definitely some serious overhead on making vfp secure and robust, but it can be done quite effectively, using some old-fashioned NTFS security along with more modern techniques, such as Houston has descibed...

Not saying this is the best or the only way to go - a server DB simplifies the security and corruption issues considerably. But at a trade-off cost: in dollars, and in the ability to port DBCs to local machines, file servers, etc. Something that vfp does extremely well, and something I need to do frequently, a very critical feature of vfp, and the overlying reason I will stay with vfp data for at least some apps, no matter what.

*Data Size* - now there's a genuine reason to go to a server DB. People can talk about splitting huge vfp data up and whatnot - but if you're in the eBay-DB category, for example, you will not be wanting to play around splitting dbfs up <g>

Anyway, everything has tradeoffs, I guess is the moral here I'm trying to get at...