Terry,

It's all relative to the time it takes to build the app in VFP backend vs SQL backend.

Here's a perfect first hand example. In a 700 employee company with 40 supervisors, the data has to be protected so that supervisors are only able to see data for their employees. Identify theft is huge right now so there are a lot of new mandates on mid-sized companies to protect this data. VFP doesn't have user roles like MS SQL which makes it difficult to create rule based data access.

Also, because a FoxPro table can be copied easily on to a CD-R and taken off site it puts further demands on you as a programmer. I'm not saying you couldn't encrypt every single field, break up the application into seperate tables for each supervisor, or a number of other things. SQL Server is choosen over VFP backend because it provides better security and better reliability with less work. That is not debateable in my opinion.

Just by the fact that client computers make a direct connection to VFP tables in a multi-user evironment make them technically more unstable and more risky as the number of users go up.

In a company with 700 employees lets just say one employee wishes to cause the company trouble. So they intentionally turn off computer, or computers, in the middle of critical posting processes. Don't think this happens??? I've suspected it, investigated it and even caught an employee doing just this very thing. He was fired a week later as a direct result, but that was after 10-20 corrupted index files in AccPac Pro Series that required at least 25 employees to be kicked from the system each time.

Now obviously you wouldn't expect me to re-write an entire accounting system so that I can use VFP backend without destroying data. The best solution is to upsize to MS SQL backend. That way a client machine never has direct connection to tables and the risk of corrupting indexes or other data is nill.

Another huge hole is that anyone can put VFP on their machine and do anything they want to your data files. A simple USE table followed by replace all field with "" can ruin a whole days worth of work even with nightly backups. How do you protect against that when you need to give the user read/write access to a table through Windows? The answer is, YOU CAN'T. Give me or any other VFP expert 10 minutes on your network and I can fill your tables with blanks, nulls or whatever I want.

If someone on your network is crafty and wants to cause you trouble, changing data through a VFP install is one way. This too I've seen happen and I've personally removed full VFP installs from many people that shouldn't have it. In one department it was even purchased for the specific reason of being able to do their "own programming". Unfortunately they never contacted anyone at IT and somone ended up losing a days worth of data entry as a result.

So I think a lot of VFP programmers think application security is the most important. Truth is, any application level security with VFP backend is a fascade. Even without full VFP, a semi-experienced junior hacker could screw you up with a simple hex editor.

As long as you remember that any security you write into a VFP app is for those who are not out to get you, it's still good to have. Most employees don't want to break the rules so I'm not saying VFP application security isn't important. You just have to remember that it's not security against a direct attack but against stupidity. If I was attacking a VFP network with an attempt to do damage, I would never even bother opening a application as that could write data into a table I would later have to erase to cover my tracks!

You also can't get around the fact that there is no easy way to modify table structure, rebuild or modify indexes, or remove deleted files while anyone is in a VFP system. All these things you can do while people are using a MS SQL backend. You don't have to kick 50 people out of a system too many times to re-build a corrupted index before you see the upside of MS SQL.

Programming aside, VFP just can't be protected from intentional sabotage like MS SQL can. So it doesn't do much good to put the blame on the programmer or say it's because your not using the tool right.

This may not matter for small companies where everyone can be trusted. But in the larger corporate clients, VFP backend becomes much less desireable.

I love VFP but the future in mid-sized corproate market is clearly with a MS SQL or Oracle backend.

Greg

>>If the database under VFP was as robust as MS SQL (or was MS SQL) then VFP would be a lot easier sell down the road.
>
>That depends on who is developing the system. They're may be engineers that can deploy DOS batch files with a DOS TXT file database that are more ROBUST than a double secret, super encrypted SQL backend built by someone with a vest full of MS certification pins.
>
>The tool does not build robust applications, the developer does.