I'll have to stick to keeping my comments here as opposed to the wiki - because every single comment I have made in the past few days - as been deleted. The wiki - where the word censorship is euphimized to the word "refactor". Clearly - I must be on the right track with a lot of this - why else would somebody delete. Well...they can't be deleted here...

Dave - while comparing .NET to VFP can be a valuable excercise, it is almost a waste of time comparing Fox data to sql server. Simply put - its not 1990 anymore. We are not limited by DBF's. By their nature, they cannot scale, they have zero security, and are difficult to remotely administer without the aid of other tools. SQL Server is extremely flexible. The presense of MSDE alone pretty much took away the last reason to use DBF's. Of course, we have had mdb's for a while - and quite frankley - I would likely go with mdb's before dbf's. I suppose that makes me a fox-hater....

SQL Server is the hands-down winner as far as flexibility, scaleability, and robust-ness is concerned.

I am all for a rationale discussion - just so long it is not a veiled (or not so veiled in this case) - as a personal shot on me. As far as a discussion concerning .NET and VFP - I too think that can be valuable. It would be interesting how some would attack that discussion. If one trys to pit Fox+Fox Data against .NET+SQL Server - I think Fox loses on data alone. As I understood the argument, the two items (App UI and Data) were linked together. That is why I made short work of it - addressing the data issue. As you saw - it did not take all that long. It really does not matter that you simply copy dbf's from machine to machine. That may have been something of value in 1990 - but not today. Using MSDE as an example - it can be setup in minutes. And yes - databases on the regular versions of sql server can be restored to msde with ease....

VFP vs. .NET on flexibility - that is a tougher question to address. Much depends on your point of view. If you primarily write monolithic VFP apps using local dbf data - then I doubt there is any way you could see .NET as being more flexible. I would say that if that is the type of app you write - stick with Fox. On the other hand - if you write client server apps - but you use remote views and have heavy reliance on the "VFP Way" of doing things - then again, your viewpoint will be skewed in favor of Fox. Again, I don't know how these people could see .NET has being more or at least as flexible. Putting the call out for the general populous to judge is a shrewed move because no matter what you put forth - the vast majority of Fox developers will still view Fox has being more flexible. The reason: it is the tool they know best - and there - it is more flexible.

About the only people I know of that could begin to see .NET has being more flexible are those developers who eschewed the "VFP way" of doing things - in certain significant ways. Developers that used products like DataClas for example, or used SQL Pass Through, Components, etc - adopted n-tier development, actually used VB, etc - these developers would at least have a chance at giving .NET a fair evaluation.

Look for a moment at those in the Fox community that have embraced .NET and have advocated its use. Then, look at the type of applications they developed in Fox.

In the end, it is about the developer and the methodology used. If you are used to dealing with remote data in a disconnected fashion - you can see why .NET is not only feasible, but quite usable and flexible. If you in the other camp - it is difficult to see how anythign can get done in .NET. The bottom line - it is about data. Notice that I did not mention a thing about the object models. I think navigating the object models is the easiest part of the process. Data on the other hand - that is where the harshest evaluations are made. How often is it said that Fox could never really be taken to .NET because of how it deals with data? Personally, I think this is a bunch of crap. I think use statements, replaces, scans, etc - could be taken to .NET. I just don't think it is a good idea for MS to invest in.

In any case, that is my take on the issue.

< JVP >

>Mike,
>
>I think it could be real useful to show a comparison/contrast between VFP and .Net can be a good thing. It could serve as something that developers using each tool can use to learn the other. If it degrades into a "my tool is better than your tool" argument it doesn't do anyone any good.
>
>>"How do we proceed? Using the UT Member's critieria as a suggested guidelines for flexibility is obviouslly going to be biased. Do you have suggestions that can even out this bias?"