Maybe we don't need to take any position. The "top" IT guy is just another pretubation in a spectrum 99% full of noise.

VFP is a great general purpose development tool. It has the "fastest" disk store technology in the world (Rushmore) as a native file system.

But - in regards to a development language - we're not programing in Fox or C or VB - we're really programming in a generalized node script language. The lanhuage of acivex and OOP property and method collections. We use vfp, or C or VB as an interface to those node scripting engines.

Now if someone needs to make an argument that his solution's scalibility better addresses this or that node engine - let him do it. We don't need to argue with these guys. Every one needs to learn/relearn the difference between a talker and a walker!

So - the argument - if it needs to be argued - should not concentrate on what we use to implement node script engines - but rather how well VFP services access to those engines and how convenient it is to have native rushmore. And how convenient it is not to have to jump through hoops like a .NET project or C project would to address VFP's rushmore. (And we know there doing it!)

I note that "Real One" media player uses DBFs!

People are hiring us to solve problems. If the mandate for the solution is beyond our skills - then we move on.

The question should be: "When a top IT guy says anything should we really care?" He's a top it guy because he is a consultant - a "microsoft partner" or someone who gets something for being whateverkind of "advertisement" Microsoft and Robert Half want him to be!

>>One of our infrastructure on a client site includes a .NET Web Service which uses VFP and WWC for the data tier. Today, a top IT in regards to the management of that infrastructure says that this solution is not scalable. They said to us that a global .NET solution is scalable. How do we react to that?
>
>Michel,
>
>I think that you should concentrate to not defending the VFP, but rather attacking the architecture long time associated with VFP, which is client-server architecture with fat/GUI client and file-server access to DBFs. Then show that VFP middle-tier components could be a great player in web-based distrubuted system running against the true transactional databases (like SQLServer). The VFP database itself is a no-go in any serious enterpise projects, but the VFP-based components are great.
>
>Try to push the idea of language-nuetral development, where components written in various languages communicate with each other using HTTP (not DCOM, not .NET remoting, not CORBA, etc.), doing their business in the middle tier, generating universal HTML-based presentation and running against major transactional databases like SQL Server or Oracle (bot not VFP database).
>
>This works for me, people don't make a big deal about VFP in this architecture - they use it together with C#, PHP, VB.NET in the same project and nobody cares about the "language" aspect.
>
>The "language" aspect was important 10 years ago, when if started with, lets say VB, you should continue with VB to maintain your huge EXE file. But not anymore - with universal presentation (HTML), universal server-to-server communication (HTTP) and universal database (the transactional one, please) - you really have more freedom for language to choose and the cost of [language choice] mistake is minimal this way. If you educate your clients about this approach, I am sure they would be more open minded about the VFP.
>
>Igor.