>Walter thanks for all your points their a very valid ones.
>as you said MS never really embrace VFP and in that you are right, but that will never happen.
>Yes MS is adding alot of data driven functions into the .net framework, many of them come from VFP, and they will certain add more, why do you think they added the .netframwork inside the sql 2005, perhaps they saw that sql speed could never be that fast if your doing massive data driven operations and you can only use tsql for that or ur doing it on the client side.
>As you said there are 3rd party people and companies developing neat features for VFP but that's it bottom line is that MICROSOFT WILL NOT DEVELOP A NEW VFP VERSION.

MSFT has never said that there will never be a version 10, although you can read it beteween the lines. And so what? VFP9 is a finished products, there is practically nothing to add to the product. And it will work for the next 20-50 years! The support will stop in roughly 10 years, but so what? I have a 12 years old BMW, which is not "supported" as such. But that doesn't mean that my BMW will not work 10 or 20 years from now, there will ALWAYS be enthusiasts willing to support and help. As is the case with VFP. You really missed something when you did not attend Craig Boyd's presentation in Phoenix last week.

Please get a life, and stop this nagging!

>you talk about fox 2.6, and at that time it micrsoft had no concrete plans to foxpro, but they never said the 2.6 was the last version developed like thay said now with VFP 9.
>
>
>>Well there might be a few reasons.
>>
>>1. Your experience in foxpro gives you a jumpstart in writing VFP applications. Learning .NET would be more of an investment than learning VFP.
>>
>>2. Depending on the requirement you might choose for VFP because:
>> Highly datadriven ERP like applications are easier to write in VFP
>> The need for plugin scripts is much easier than in .NET due to the runtime compiler
>> When your applications works with lots of data on the client side (e.g. reporting, analysis), VFP is more resource conservative (data is flushed to disk, iso of process memory) making the VFP application better suited to run on citrix, terminal server.
>>
>>In an application I'm working on, the data dowloaded from the SQL server is seldom matching the GUI representation. With the downloaded data there is a lot of data munging going on. In the real world there also is a disconnect between the representation of data and how its stored. I do not regard SQL server to be the tool to easily do that. The strength of VFP made it possible to write the application the way we did.
>>
>>One example is our appointment system. It is constructing a calendar table out of half a dozen other ones: Rosters, Staff, Patients, departments, Appointments and blackouts. The mix of SQL and Xbase based DML makes it possible to munge this data onto any representation you want relatively easy. Also the searching for appointment slots would be a lot harder to program without the help of xBase dml.
>>
>>In short, we download the data we need from the SQL server in a raw form, and once on the client, mung it into a form that has meaning to the user.
>>
>>I totally agree that if you want to develop a record entry system with simple reporting, you could choose .NET without suffering the consequences in regards to data processing.
>>
>>Another key point of out application is the possibility to write scripts to meet specific client needs. Code is stored in memo fields and executed in VFP. Though in .NET you can do reflection, it is not something that matches the VFP runtime compiler.
>>
>>For support we have a command window, to make it possible to execute VFP commands on the client side, strenghtening support in case of issues.
>>
>>Now this application supports both SQL and VFP backends. It would have looked entirely different if we did not have VFP to program it in. VFP has made it a product that distinguishes us from our compatitors.
>>
>>One former member of this forum, a true .NET promoter, said. The right tool for the right job.
>>
>>
>>Now back to MS support for VFP. We all know that MS never really did embrace VFP. It always was a stephchild. However, being a VFP programmer since Fox2.x, I'm not worried about new developments in VFP. Lots of 3rd parties are developping neat features for our applications. Even microsoft uses them to improve VFP. A couple examples of that are:
>>- Lisa and Colin for their incredible work on VFPs report writer.
>>- Craig boyd who does tremendous work to give us poor programmers interaction with .NET and simular functionality
>>- Those guys (I can't remember their names) writing the CTL classes for XP themed controls like status bar, scrolling containers, etc.
>>- The development going one of using GDI plus to render graphics more easily. Bernout Bout for example showing us neat transparent forms without the controls being transparent.
>>
>>In short, I see huge activity in the VFP community to extend VFP9 beyond what it offers now. I do remember the time FoxPro 2.6, where MS did not have any concrete plans for VFP. I have no inside information, but I think that at MS people now are realizing the great features VFP has had for years, and that now with .NET they realize the market wants this tight data integration. I think that MS now better appreciates VFP than a few years ago. However what they are going to do strategically is of course difficult to say.
>>
>>A lot of programmers went for VB, MS access. I won't make that mistake. I'm convinced that MS in time will give us a tool with the same and better feature we currently love in VFP. Good chance that is going to be .NET, but in its current form, it is not there yet. For me al good reasons to sit back, wait and see what is going to happen in this area. I don't see a product that really is an alternative to me at this point.
>>
>>Walter,