All I'm trying to say is that in large network environments where you can't depend on your employees to behave all the time, then VFP backend becomes more complex. You mentioned specific technology implmentation once again such as using tables without table buffering. What I'm trying to tell you is that in a complex accounting system like AccPac I don't have a choice to re-write the entire way they integrate with VFP. But AccPac does offer a very solid SQL backend. So what is more cost effective? Re-writing an entire accounting system to imporve VFP reliability or upsizing to MS SQL which will always be more reliable anyway.

So you keep saying, 'stop blaming the tool' when the problem is hundreds of thousands of lines of source code that have already been written. Much like John P. you seem to view every situation as starting from scratch and writing everything yourself exactly the way it 'should be'.

I also noticed you throw in 'webservers running Foxpro 2.6'. Let me be clear. Webservers offer far more protection of VFP data than a multi-user network where you have to give end users read/write access to an entire table through NT.

I've never said that Foxpro was a huge security risk in web applications. There you have people with annonymous permissions that must first hijack IIS to gain any hope of getting at your tables. That's a lot different than a mapped network drive where the user has fundemental NT permission to read and write into your table. Just by putting a webserver behind a firewall and restricting everything but Port 80 you have 1000 times better security than any VFP multi-user network.

Also a web application can handle hundreds or even thousands of users without saturating network bandwidth. I've used Everest manufacturing very efficiently when there are under 10 purchasing agents involved. But when the numbers start climbing and the BOM gets huge, network bandwidth gets saturated. A 4 million record table that slows down a 10 user network, will bring a 50 or 100 user system to a grinding halt. In web environments this is simply not an issue so a SQL solution isn't as vital for maintaining performance.

You say that MS SQL is clumbsy but yet fail to address the fact that if anyone is in a VFP table you are severely limited in what you can do to manage and maintain tables. On a large network, nothing is more clumsy than kicking all the users out of a system to do what would be considered mundane database maintenance.

Also lets not forget that Microsoft includes FREE distributable MSDE with VFP. It's possible to deploy at low cost to the client but offers many of the security and reliability advantages of the full blown MS SQL.

Greg


>>It is much easier to fire a government civilian employee now. The regulations have changed and it is more competitive. Plus, the majority of workers on government installations are actually contracted.
>
>You are aware that the first reported (1994) computer virus (video board virus) was created by a government employee. He wasn't disgruntled - just bored - and too much free time:-)
>
>
>
>>
>>
>>>The government is not the same model as civilian. Civilians can get fired. Cicil Service Unions are notorious! In my estimate - all civil servants are disgruntled! A civilian employee inclined to be un productive and not with the program will usually loose their job before it gets to the point (providing they have the skills) that sabotage occurs.
>>>
>>>Also, cicilians seem to take a personal interest in the well being of their operation. They don't want to loose their jobs.
>>>
>>>I can break any system - regardless of how secure it is. It can be SQL, VFP - or what ever, put me at a console, give the same privlidges the so called possible destructive employee has and I will make that database unuseable in less than 2 minutes.
>>>
>>>
>>>
>>>>Hi Terry,
>>>>
>>>>The number one security risk is not from the outside, but an inside employee. That is where the majority of security breaches occur (unintentional as well as intentional) and that includes corrupting data by disgruntled employees. I saw this first hand working for the government for 7 years managing the network. Of course when you have literally thousands of users on the same network you have to be a LOT more security concious. And that is on the non-secure systems. :o)
>>>>
>>>>Tracy
>>>>
>>>>>I've heard this security argument before regarding some disgruntled employee with super-power user skills sneaking in and messing up data becuase he got fired!
>>>>>
>>>>>I've heard that so many times it makes my brain itch. If it gets you work and it sells SQL - and thats what you need to do - the press on.
>>>>>
>>>>>It has never happened - every time this story floats - it's always in the hypothetical. It's BS, and you should know it:-) It's like the Donkey women in Laredo - everybody talks about her - but no one has seen her!
>>>>>
>>>>>It's "could be myth" to sell over priced - clunky solutions using fear tactics. I guess that's the environment we're in today. Most damage comes from the outside - not in-house. If I were an IT manager, and some consultant sang that song for my little mom and pop - I would laugh him out of the office:-)
>>>>>
>>>>>>>The tool does not build robust applications, the developer does.