>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.

To be honest, I don't have a clue why they did that. I think it was a big mistake to get it in there for the simple reason that people are going to abuse it. A database server is a database server and should not act as an application server. If you want to program additional functionality that you should do that in a different layer. IOW, I don't know what kind of problems they are solving with this. I do see that they are creating new ones.

The fact is that in the ever evolving software market there is a need to store data temporarely and have quick access to it. In general it is used to populate dropdowns, other rather static data, metadata, such as userrights, etc. If you're storing it on the SQL server, you're going to stress the resources of the SQL server, which is not what we want.

If you have a client that is not designed to work with data, you'll have some problems to solve as well. This is exactly the area where VFP shines. It is capable of giving you solutions where data is stored relationally in every tier of your product.

Sure the .NET guys are beginning to see this, however .NET was not designed to do this from the start and they have to come up with certain solutions. YAG, told me personally that this is one of the big challenges in .NET. as it currently is build upon ADO.NET which is a memory based interface. Currently data is stored in an objectmodel with arrays. It will be challenging to flush this to disk in a simple fileformat (XML is to complex and slow) and the program not loading entired arrays when only one element is addressed. Having client indexes IMO are about imposible to do.

AFAICS, what ever solution they come up with any time soon, it will be inperfect. It probably will take a major redesign to actually integrate data with functionality the FOX (and yes there are examples of other products too (ERP/CRM) packages) currently has.


>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.
>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.

Maybe I've missed it, but where did MS EXPLICITELY tell us there won't be a next version of VFP?
All I've seen is that currently there are no PLANS beyond sedna, telling me that they themselves don't know yet.


>>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,