Walter,

Where I think Perry is coming from (I work with the guy) is that there are a lot more .NET jobs out there than VFP.

As far as .NET versus VFP apps, the only people qualified to give a sound opinion are those who have used both technologies to build database apps from the ground up. However, their honesty on the matter depends upon whether or not hidden agendas are being orchestrated.

As for me, I can only base my opinion on my experience. What other folks SAY is not my experience. I, therefore, avoid basing my opinion on the opinions of others.

As far as .NET goes, my experience is that I have never seen a database app in production. I have seen feeble attempts (and millions) wasted on Java database projects. I have seen lousy VFP apps in production. And i have seen great VFP / SQL Server apps in production - mine, of course >)

I think one of the main problems developers have is burn-out. Contrary to what some may think, burn-out is caused by the absence of being excited about one's work which is usually caused by apathy with respect to learning something new. Some folks have chosen to take VFP to the limit. Some (guys like RickS) have exceeded those limits and have moved on. Many, however, are caught in the abyss and will remain there until it gets too painfull.

Personally, I am approaching the limits on VFP. However, SQL Server offers many cool challenges and I can keep the juices flowing leveraging it with VFP.



>Perry,
>
>>I have not talked to one single person doing dotnet development who is having problems with the tool. Not one. And since I have a VFP background, quite a few of these folks came from the VFP world. I don't hear any complaints.
>
>Well, I know a few. For example talk to John Ryan. He knows where to place VFP. Talk to JohnK, he said publically that he could not advise VFP-er to jump to .NET beeing the successor of VFP. I've seen a couple of messages of RickS stating the problems with data in .NET. AFAIK he still uses VFP quite a lot. Talk to jess banaga, who has a .NET application that simply performs poor.
>
>>And I don't think that history is quite as you propose it is. I really don't think that the decrease in the usage of VFP that began 10 years ago is totally the fault of MS marketing.
>
>>Many corporation's quit using VFP because they wanted a more robust database environment. Such as Oracle, SQL Server, etc. They also found that VB functioned just as well as a front-end as VFP could.
>
>There are great difference between VB and VFP and I know quite a lot of big companies that used VFP and probably are still using it because of its database capabilities. The reason of the 'decline'' of VFP is simply because other tools entered the market that were resonable to do the job. Still VFP with its local database engine has major advantages in many type of projects.
>Why do you think there is such fuss about LINQ? Why are so many article about .NETs future data integration referring to VFP ??
>
>>Not that I would support his speaking tactics and style, but John Petersen made some posts here about how he was able to accomplish his goals quite nicely with SQL Server/VB. There were many here who wanted to learn from his experience and many here who just wanted to slam him at that point.
>
>Exactly, you say it right: HIS goals, not saying anything about the goals of others. JVP really did not understand the value of the database engine. He simply had no clue what he was talking about. Time has proven he was wrong. Microsoft now is admitting the importance of deep data integration and why it needs to be in there, thanks to the VFP - team.
>
>The problem as JohnRyan said, is that there are VFP developpers that really develop in the VB/SQL server style. Not doing much with the local data engine. No post processing, no data munging etc. Those indeed would have little trouble to go to .NET/Java/Delphi or whatever. When things start to get a little more complex you're faced with problems that take a lot of time to solve. How many times did we see messages over here about post processing ADO.NET recordsets ??
>.NET currently is a huge step backwards for those who heavily use the local database engine for all kind of things (not just DBF style access). Things will improve on this area as we have seen from microsoft with the LINQ project. But lets first wait and see.