Given the numerous bugs/things that have been broken in VFP 8 - that is a non-starter. I have looked at the view designer - and most of the improvements come by way of the cursor-adapater - which is a kludge-o-matic way to address the problem. Perhaps it is true the view designer has "improved" - but the fact remains that the update logic is too closely coupled with the storage mechanism. And - it is a solution that ties you into Fox.

And to be accurate - I did not say I would reconsider my stance on views. Rather, I said I would consider looking at and re-evaluating views if the landscape changed. The landscape has not changed enough for me to change my primary conclusion.

< JVP >



>John,

>
At some point we had a discussion about views where you stated that *IF* VFPs view designer improved you would reconsider your standpoints about views. With VFP8, the view designer indeed has been improved a lot as well as some enhancements of using shared connections with views stored in a database. I think you should re evaluate your standpoint here...
>
>>As time goes by, more and more come to realize that Fox does to have the presumptive advantage anymore of speed and flexibility. I do understand the speed and dexterity with which you can develop apps out of the Fox box and not looking further than that. And for your niche - it sounds like it is working well for you. My point is that while there are many Fox success stories out there - it is not enough to carry the day for Fox. The VAST majority of the rest of the world is looking elsewhere. Is much of this due to the MS marketing machine? Sure. But in all fairness, the MS Research Folks have put their $5 Billion annual budget to good use.
>
>About your niche statement: With the number of different development tools more and more tools become a niche. It simply has to do with the variaty of tools.
>
>Whether something is enough to carry the fox is not up to you nor me. Anyways about the $5 billion spend mostly on .NET, I can see the benefits of that environment esspecially in the InterNET area. However what really holds me back is the lack of a local dataengine. This is precisely the big advantage of VFP over .NET. Handling local data is far more inflexible than with VFP. Doing all the processing of data on a database server like SQL server, is for data intensive applications a real problem. Storing meta data in the executable is cumbersome, processing it without uploading to an external database engine at least difficult. In any case, data driven applications seem to have a fair disadvantage in terms of performance and flexibility when written in .NET for the sole reason it has to let external components do the task. Of course with this becomes the problem of standardisation of handling data internally. One would use MSDE, the other SQL-Server, Oracle, VFPs through OLEDB etc.
>
>This is exactly the reason I was interested in the F# project. However that project has been discontinued. I guess we will see this gap close at some point in time, but until that time, I can only see disadvantages in moving to .NET:
>
>- No local dataengine which makes it very difficult to rewrite my applications to .NET with the same degree of flexibility.
>- At this time I'm swamped with work, so I don't have time to work myself to the expert level in .NET
>- .NET is too immature at this point. It has to prove itself first. See first point.
>- I don't see a lot of .NET projects done arround me. I don't see companies which have a huge investment in some tool and code jump .NET from one day to another, nor do I see a lot of clients with existing VB, VFP, ACCESS applications now jump the .NET wagon, just now they've just about settled everything (Yes I do think the timing of .NET was too late)
>
>You've always made the statement: use the right tool for the right job. Appart from that I don't neccesarely agree with this statement (I will use a hammer to drive a screw in, if I don't have a screwdriver), at least you've to agree that according this rule VFP developers might have it right to develop in VFP.
>
>Now you seem to have changed the rule into: Use the more popular (hype) tool for the job. IOW, buy a pneumatic hammer because it will drive in nails much easier, but also forget that:
>
>- for a pneumatic hammer you need to purchage a compressor (.NET: Investment in code)
>- Since the pneumatic hammer was just invented, it has some problems with nails getting stuck (.NET is immature)
>- If there is no power, i'm screwed. (No running .NET on older OSs).
>- It is difficult to get a nail out with a pneutmatic hammer (No local dataengine)
>- You need to school the carpenter to use it to prevent accidents (.NET training)
>- You can't use a pneumatic hammer everywhere (speaks for itself).
>
>There is no doubt that the pneumatic hammer is a great invenstion, but does it make the normal hammer obsolete. I don't think so.
>
>Your role in this seem to be to tell everyone to use a pneumatic hammer for every project, while it does not make sense for those projects/carpenters/tasks where a normal hammer is the better tool.
>
>I guess your next tactic will be in saying that the local dataengine advantage is insignificant an will do the same with this argument is you did with VB's inheritance:
>
>- You can workarround inheritance and for middletier objects it is insignificant.
>- When the specifcations of VB.NET came, you told us: Great, VB now will have inheritance, we all should more to VB.NET.
>- Until it became clear that there was no easy upgrade for VB application and you briefly joined .NOT
>
>I can see the following happening:
>- "The ommission of a local dataengine is insignificant, You can use MSDE"
>- When .NET.next comes with a local dataengine I can see the headlines in the paper (article written by JVP): "Local dataengine greatly improves .NETs flexibility"
>
>Sigh.....
>
>>I continue to go back to Orlando 1993 - when Roger Heinen announced what was then called the unified tools strategy. Some argue that MS has switched course - and to a degree that is true - insofar as tactics are concerned. For example, COM vs. .NET - that is really a tactical issue when you get down to it. The real strategy has been the unified toolset. And 10 years later - when you look at .NET, Longhorn, Yukon, etc. - that is precisely where we are at. And finally, in the June or July 1993 FPA - John Hawkins wrote his prophetic piece when he did a 1 year post mortem on the MS/Fox Sofware "merger" - really a stock acquisition. Hawkins had several prophetic questions like "Why did MS acquire Fox in light of Cirrus (became Access) and VB - which at the time was at version 3.0. 10 years ago - Hawkins saw the writing on the wall - and pretty much predicted that Fox would never be front and center.
>
>I don't knwo the article, but I do know that MS bought Fox to get rushmore and the developers which could help MS to get the expertise to build database development tools. IOW, as strategic choice. OTOH, they could not ignore the large population of FPW developers. FPW 2.5 was already about finished so MS did little more than putting their company name to the splash screen.
>
>I guess VFP3 was really more a research project that became succesfull. Since the xBAse crowd was calling for more they just did not discontinue it. For all those people who are complaining about MS supporting VFP, just imagine where we would be if MS did not buy FOX software. Would you really think we would be better of ?
>
>Walter,