>This smacks of the arguments on here a short while ago as to the viability of VFP in the market.
>
>I was trying to say that backend independence lets the developer agree to whatever database policies the customer may have developed at considerable cost, rather than insisting on the developer's preference. If you're saying that your customers don't have such database policies then lucky you. ;-)
>
>FWIW I think there may be some threads here from years ago about doing heavy work on the server. Plain CRUD is one thing but heavy munging can severely impact performance- unless you take it off the server and use some of the grunt of a typical Windows PC. ;-)

About 2 years ago I assisted a developer in researching data problems on a system that was across the U.S. He spent a lot of time trying to access their data remotely and really look at it. I opened up VFP ide and connected and brought the required data down in a flash - literally. He was so amazed he made me walk him through how I did it. This was an "expert" developer who looked down on VFP for years and saw it as the "user's programming language." I was always amazed that so many didn't know the real capabilities and benefits of VFP because so few actually used it in ways that demonstrated it.

I am not trying to knock anyone, but experience has shown me that those who insist that all the data processing and munging should be done only on the server have never experienced the top of the line server being brought to its knees by heavy data munging by multiple users. IMHO, the customer's business requirements (taking into consideration security issues and coding/planning for that) determine where the data munging occurs - not my own personal preference. I cannot count the number of times I've gone in behind a developer and moved the heavy crunching from the server to local because a business couldn't function with the data being munged on the server (including with .net apps now) - that's after bringing in "experts" to provide the latest, greatest system and to configure and manage it. It's easy to say "I've never had problems" when you've never had to work with serious data crunching requirements. As to Oracle, I spent years working on Oracle for the government and IMHO, SQLServer is not up to it's security levels and capabilities (yet). SQLServer certainly beats Oracle in ease of use (as did their original servers and networks beat Novell in the same way when Novell was always the best C2 certified system), but not in other areas that mean more to some customers. Who your customers are quite often is the determining factor as to how you design a system. What works for one may not work for another. If someone is willing and able to turn that business down, more power to them. Moreover, when it comes to VFP versus .Net, I get really tired of the suggestions that a .net designed system is slower than its VFP counterpart because of lack of experience and knowledge of the developer in .net. When you've brought in all the "experts" (MSFT, MVPS, and other recognized data handling experts) to help design for speed (and paid the *BIG* $ for them) and it still doesn't compare, that's a serious issue and a real concern. Of course, there are clear benefits (features and other capabilites) that make .net a better option in many cases as well.

Ok, that was my 2 cents and probably not even worth that much...