As Mark Twain is supposed to have said "The news of my demise are somewhat exaggerated" or words to that effect. The same could very well be said for VFP.

Lot's of people have tried to talk VFP into the ground for years, and unfortunately MS has done little or nothing to dissuade us from the notion that VFP is a niche product that's on it's way out.

More's the pity, because it makes it very hard for developers to convince customers why they should go with a, outside the circle of the blessed 100 000 or so, virtually unknown product. Removing it from Visual Studio .Net was a unfortunate signal to send, and in my opinion marginalized the product even further.
Enter the downward spiral...

I know for a fact, that even the staff at Microsoft Denmark barely know of it's existence, but I am equally convinced that, if the marketing people at Redmont only would tout it as they do with Access or VB, nobody would be speculating about it's untimely death.

While it will not do everything you ever wanted to do on a computer, it's, shortcomings and all, still my develoment tool of choice for database development against client/server DB's, simply because it brings knew meaning to RAD and runs, well, like a Fox.

VFP programmers have for years been programming OO code in a manner and style that VB or C# programmers still only dream about, and all of it without lots of incredibly stupid curly braces, semicolons and intricate syntax.

I have not even seen VFP 9.0 yet, but I know Ken Levy to be a both bright and reasonable guy, and if he says it will fly, I'm confident that it will indeed do so.

That said, a bit of passion in selling it, along with tight integration into Visual Studio .Net and it's myriad of classes, would surely help a long way towards keeping it around for a while.

To the people who actually built the thing, my sincere congratulations and thanks. I'm very much looking forward to getting my copy.

After the usual frustration and gnashing of teeth, I will, by the time SP1 comes along, as the saying goes, probably be loving it.

I've been using VFP and it's predecessors for 15 years, and I gotta tell you - VFP is dead. There are few jobs these days, and most people still using FoxPro are busy converting it to something else.

>> What's more, Microsoft has embedded SQL into the FoxPro language...

Hmm..I seem to recall this was done about 10 years ago.

VFP9 - Same Old Stuff with a better report writer. Save your money....Alas, the king of desktop database apps is dead....

Isn't that odd? I have made a good living with VFP. It's tight, fast and a delight to use.

Let's hope the good people at Beta News will remove your unfounded attack as soon as they see it.

Huh, funny how I'm seeing more VFP jobs posted in recent months than in a long time.

I too have made a good living from VFP and FoxPro and FoxBASE for more then 15 years. But my "attack" as you called it is not unfounded. Look at the numbers. The number of VFP developers and jobs has been dropping every year for years. My current project is a conversion of a large VFP app to dot net (a type of project that we are seeing more and more of these days). We spent a lot of time evaluating our options, talking to "experts" and consultants. In the end, we could not find one person that would stand up and say that we should keep the product in VFP. We even hired a well known VFP developer, and they too agreed that VFP was no longer the path to follow. Microsoft themselves won't promote VFP. Wake up and smell the ashes, guys. I love VFP, I've used it and it's predecessor for over 15 years, but it's all but over for VFP.

I don't see how you can call ook's rational opinion an "attack." You might disagree, and to a small extent I disagree with ook, too. But for the most part, he's right that VFP is riding into the sunset.

VFP has been a great tool and Microsoft has done an admirable job of equipping it with modern capabilities for people with existing investments in VFP and xBase, but with each passing year VFP becomes a poorer choice for developing major new apps. Basically, people write new apps in VFP if they need a small quick-n-dirty which can reuse some existing chunks of VFP code, or if they need to access DBF files (especially if there are associated DBC/FPT/CDX files). But hardly anybody who can justify the cost of major rework on an existing VFP app will actually do it in VFP. If the app needs a large enough amount of work, and there budget is available for a lot of work, there are very few organizations left who wouldn't rewrite in something else.

There will still be lots of VFP code written 10 years from now, but VFP has matured as much as it ever will. There will never again be a thick FoxPro Advisor with exciting new techniques for Foundation READs. You are never going to download VFP source code for a BitTorrent client from SourceForge. In other words, VFP is not going away, but it's not going anywhere.

If you compare the typical VFP code written in 1997 with what was typical in 1992, you could still see progress happening. The language was still evolving, people were still finding new ways to exploit it. If you compare what people wrote in 2004 with what they wrote in 1999, you see that they've added SYS(2700) to enable Windows XP themes. That's pretty much it. Comparing VFP 9.0 to 3.0 is an insult to the 3.0 team. The new report writer may be a nice productivity-booster, but how can you compare it to the OOP extensions, true event handling, DBC-based triggers, and Win32 support added in 3.0? I was in San Diego at FoxPro DevCon '95. I knew Taz. I worked with Taz. Taz was a friend of mine. Mister Europa, YOU ARE NO TAZ.

There are a certain number of programmers who will quietly make a comfortable living on VFP for the next decade, because there are too many niche LOB/vertical apps in the world which their owners cannot justify rewriting, solely for the sake of moving to a more popular/modern language. If you're one of these folks, I wish you the best and I thank you for doing a thankless but necessary job. But let's face reality: the best days of VFP's life are in the past. It's a dead-end product.

A "rational opinion" is one thing.

"Most people working in Fox are converting away from it" is neither founded nor an opinion. It's an attempt to be a statement of fact, with no actual data to back it up.

And the reason you're not going to download a VFP BitTorrent client from SourceForge is that VFP is a data language. The only data handling here would involve tracking what you've downloaded.

Now, downloading a trucking dispatch application written in VFP from SourceForge, _that_ I can see.

SQL has always been around in FoxPro since at least 2.6 for DOS. It has always been fairly non-compliant with the ANSI standards. Fox 9 greatly improves FoxPros SQL ANSI compliance and makes it much more similar to Microsoft SQL Server's SQL. This is great news, because FoxPros greatest strength is its local data processing, and now Microsoft SQL programmers can take advantage of the new Fox SQL without a learning curve on the SQL itself. Also, many of the arbitrary limits have been removed, like the 24 item limit to the IN clause list.
(select * where pk in (1,2,3,4,...,25) would err and is now fixed.)

Here is a list of SQL enhancements taken from the Fox 9 Beta documentation:

In VFP9, there is no hard coded limit for amount of joins or amount of subqueries used in a SQL statement.
There is no hard coded limit for amount of UNIONs in a SQL SELECT statement in VFP9.
There is no hard coded limit for amount of tables referenced by a SQL statement in VFP9.
For VFP9, we will remove the hardcoded limit of 24 arguments that are allowed in a SQL IN statement.
VFP9 will allow for multiple subquery nesting. Correlation is allowed to the immediate parent. There is no hard coded limit for nesting depth.
We will allow for UNION clause in a SQL INSERT statement FROM clause.
SQL - Allow GROUP BY in Correlated Subquery
SQL - Allow ORDER BY in Conjunction with TOP N Inside of Non-Correlated Subquery
SQL - Allow Sub-SELECT in FROM Clause
SQL - Allow Subquery in SELECT List (Projection)
VFP9 will allow subquery as a column or a part of expression in projection.
SQL – Allow ORDER BY Using Field Name with UNION Clause
In VFP8, as soon as one uses the UNION clause, you need to use numeric references
and can no longer use the field name for the ORDER BY clause.
In VFP9, we will remove this restriction such as in following example:
SQL – Allow Subquery in UPDATE SET List - VFP9 will allow for a subquery in UPDATE SET clause.
SQL – Support for Correlated UPDATE
SQL – Support for Correlated DELETE
SQL – Optimize LIKE "sometext%" Performance
SQL – Optimize TOP N Performance
SQL – New Support for Local Buffered Data
SET SQLBUFFERING ON | OFF - If data is not buffered, we simply grab from disk.
SQL – Allow Aggregate Functions in SELECT List of a Subquery Compared Using { | >=} {ALL | ANY | SOME}
SET ENGINEBEHAVIOR 70 ! 80 ! 90 - We will update the SET ENGINEBEHAVIOR command to change the SQL behavior
SET ENGINEBEHAVIOR 90 - Specifies that VFP treats SQL commands with the standard VFP 9.0 behavior.