Perry,

>I've always wondered about some of your prior arguments here. It now seems to me that your arguments are highly based on emotions.

I don't think so. When I've got to choose between two products I tend to get all the details to compare them. There is no doubt that many applications could be written in a variaty of development languages, but for having the ultimate power the devil is in the details.

The problem with .NET is that I don't have the details, and no-one will be able to provide them until .NET has proven itself in practice.

>VFP is going anywhere anytime soon??? I didn't know you were in a position to make that decision. Maybe you are not aware of the situation, being based in the Netherlands. VFP is the only computer product I know of where you have to go to a specific place (Hentzenwerke and now Amazon also) to buy books on the topic. VFP may be powerful, but it has been loosing major market share every year for at least the last 5 years. Even this year the number of VFP Devcons has shrunk. There has been a very serious decline in the number of VFP jobs in the US over the last 5 years also. Given these realities you have to seriously question the long term viability of the product.

To my honest opinion there will be a VFP 8 available. That means that VFP will be supported by MS for at least a couple of years. About the srinking market share for VFP, do you have hard figures to support this? As I have read that the last DEVCON attrackted more attandees than the years before, I don't share your conclusion. As for finding Jobs, I can't verify your observations, but don't forget that the world is a lot wider than the US only. In the medical world VFP/FOXPRO is a very commonly used product for building applications for may years and I don't see that change in one or two years. Further as a standard software developer, I'm not depended on what the 'world' says about foxpro, My clients don't even know my applications are written in VFP. Personally, I regular see VFP programmers asked (in combination with other skills) in the adds of various papers. Further, once in two months I'm called by headhunters for a particular VFP job. I don't draw the conclusion I can't earn money in my corner of the world. Now might you say, "In your corner of the world, things might be different", but dont forget that the USA is also just a corner of the world, though it is a bit bigger than mine. Don't forget that in western europe there live just as many people as in the USA.

>The reliability that SQL Server/Oracle brings to the table, as well as the enhanced level of security far outweighs the cost difference to many, many companies. I don't know what the economic climate is in the Netherlands right now, but I can assure you that even with the economic downturn in the US you don't here of stories of companies junking any of the big DBMSs to go with VFP. You might here of people switching from Oracle to DB2 or to SQL Server, but I've never heard of anyone switching to VFP.

You forget that SQL-server and VFP are NOT mutual exclusive. If you want security and more stability SQL-server (or any other server DBMS) is a good option, but you still have to write a front-end. In this arena VFP still has a fair advantage of the competition because of its local data engine. In VFP you can choose what to process on the server, and what to process in VFP data engin locally. If you're into data driven applications (Look at Navision Financials), you easely can see the value of such powerfull local dataengines.

Further, larger companies might install a SQL-server and this is nothing wrong, since VFP can be a greate front-end to it. How about applications that do not require such step ? How about those small and medium sized companies that do not have (or want to have) the budget to run SQL. How about administration ? MSDE ? Maybe an alternative, but installing and maintaining solutions with MSDE is a lot more difficult that the build in VFP data engine, aside from the fact that MSDE does not scale too well. The choice between SQL and VFP has many sides. Sure is that VFP is cheaper, a lot easier to install and maintain than SQL. If you don't have a high need for securing data and endurability of data then SQL might not be the most logical choice.

>As far of record oriented commands, have you ever written anything in TSQL or PL/SQL or know what they are?????

I absolutely know what they are and how they work. However they still have a set oriented origin. For example take a hierarchy of employees and bosses. Each employee can have a boss, Each boss is an employee and can have a boss on its turn. Now the question: How to search the upper boss of any given employee.
In xBase:

FUNCTION FindUpperBoss
LPARAMETER nEmpId

IF !USED("Employee")
   USE EMPLOYEE ORDER TAG EmpId IN 0
ENDIF
DO WHILE Emp_BossId <> 0 AND SEEK(Emp_BossId,"Employee")
ENDDO
RETURN Employee.empId

How are you going to do this in TSQL and PL/SQL and how does efficiency compare to xBase ?

>>Johns, mistake is that he thinks that VFP has no characteristics that have an advantage over VFP. He clearly underestimates the power of VFP in the data arena. Futher he ignores the tremendous investments in code (e.g. frameworks) people have in VFP. Well go out and throw it all away ! Unless, maybe like john, you don't have invested much into code and frameworks.

>Sorry, but I've yet to be in a meeting where someone says "VFP has sooooo much power. How can we talk about switching?" I have been in several meeting, especially lately, where the discussion is about what the next jump should be to get past some of VFPs limitations.

Like ? Well of course VFP has limitations, like any development product has. If you would ask me what would be the best front-end for a database in SQL-server, I would inmediately answer VFP. In vfp you'll have the choice to solve data issues on the SQL-server or in the VFP local data-engine, more than in any other competative product. This is esspecially important when you've got to run a highly data-driven application with lots of variable META DATA.

Walter,