Hi Perry,

I agree. My points were technical, not on what's currently happening out there. There are many cases where the technically superior gets hosed out of a market; ie, Betamax vs. VHS.

Your points on the reality of the corporate environment are very good. If I were magically transformed into the CIO of a major corporation, I could not recommend VFP as our major tool choice for all the reasons you state. However, I've also sat in meetings where VB and the VS tools were not selected because they weren't taken seriously in billion-dollar, critical situations.

Specifically....

>1) It's difficult to hire qualified VFP developers into the corporate workspace. We went thru a hiring period several months ago and it was awful. 100% of the resumes that showed someone highly technically qualified, also showed dotnet experience. We made an offer to several of those candidates, but they all took dotnet jobs.

One would expect this, considering the lack of VFP marketing and support by MS in the strategic arena for 10+ years.

>2) DBFS. Corporations started swearing off VFP 10 years ago and DBFs are one of the main reasons I think. The fact that VFP makes a great front-end is meaningless. To the corporate manager, they see problems related to DBFs, and put VFP on the not-supported list.

I can't disagree. I've seen the falldown of DBFs in these areas. The Cursoradapter maybe goes a long way to mitigating these concerns but, too little, too late.

>3) VFP developers in general. Most VFP developers I've come in contact with are used to working by themselves or maybe with 1 other person. They just don't fit into the corporate, big team environment that well. Not that they couldn't. But most VFP developers are older, more set in their ways. Difficult, if not impossible to get them to adhere to corporate standards. Something critical if your working with big teams.

Hey, I resemble that remark! LOL. Again I agree. Most of us are in our 40's and come from a time when the "lone gunman" coder ruled.

But....all of this applies solely to the corporate environment. VFP still excels at the simple line-of-business app for small and moderate companies that need a fast app that does a credible job.


>>Hi Rick,
>>
>>When it comes to high-end apps in an enterprise environment, you are undoubtedly correct. In both cases, VFP or .Net has to broker data with a remote source and the techniques one uses goes a long way towards the success or failure of the project. In both cases, however, it's clear that a data broker is needed at the data server level to ensure timely and efficient delivery of information. If the application is only served raw data and all joins or other SQL functions are performed at the client level, then VFP has an advantage as a data-munging app as .Net, frankly, sucks at that.
>>
>>As far as small and medium business apps with no more data needs than a file-server setup or totally local data, VFP beats the crud outta .Net and will probably do so for the forseeable future. It's structurally superior in that environment.
>>
>>I guess what I'm saying is that when a database server is required, the query workload must be at that level to make a .Net dumb client work. If there's a mission disconnect between data and client, as is usually the case in the corporate environment unfortunately, .Net falls on it's butt and VFP is - at the least - an equal to the task.
>>
>>And maybe that's the crux in marketing .Net - you cannot ignore data.
>>
>>>>Well, the fact that I never needed to handle a million records does not mean it might not be an issue for others, I have a program that generates 2D graph that needs near 75K records, and it is simple, so I can certainly see that more complex or 3D graphs requiring a million records. But, even if you can stream the data a record at a time, why would you do it if you can pull the data faster at once to process it locally to generate your graph/object or whatever visual representation you need?
>>>
>>>Streaming does not imply pulling data slowly or reconnecting. In .NET using a DataReader streams the data while connected and you access the data while it's coming down one record at a time. Add to that the ability to do this on a background thread while other UI or process work takes place and you have the ability to very efficiently pull data down to the client. Streaming data in this fashion is very low level and likely going to be faster than streaming data into cursor for example - certainly than synchronously waiting for a query to complete.
>>>
>>>Look, my point is not that .NET is necessarily better at doing this - it's just different. Like I said a bunch of times before here - if you think of doing things the VFP way in .NET you'll think it sucks. But with the right approach and some different concept you can - most of the time - provide the same functionality with the same or better performance. People are writing high end applications in .NET every day and people write high end applications in VFP. It can be done in either and if you know how to use the tools either allows you to do it with reasonable ease.