Hi Kevin,

>"That is a very pompous statement, don't you think. "

That was in response to Mr. Meester - hey, that's pretty good...<bg> - sweeping generalizations about the rest of the VFP community... Of course, nobody jumped on his ass. It was a fairly subtle slam at the community, but one that did not pass by me...

>I had a pretty good chuckle and said well he does seem abrasive,

But yet, you did'nt see Mr. Meester comments being abrasive at all....right???

>but I still need to find out what he says about VFP C/S stuff. I have developed C/S apps in SQL*Server and Oracle for some pretty large companies and well, I used Remote Views almost exclusively. I need some more information about the weaknesses of Remote Views. While I have invested a lot of time in dealing with remote views, I also don't mind changing directions if it means better, more stable and expandable apps.
>

All right then, the short version. Right now, you VFP C/S apps are two-tier in nature. All of your data access logic is buried in your client. After all, Remote Views are a VFP feature. What happens when your underlying schema changes? Your RV's break. Sure, you may have a clever way to get around it, but that is the point, you need to get around it. Remote Views are also tied to ODBC, not OLE-DB. So, if you needed to pass data around to other components, you would have a difficult time since you cannot pass cursors around.

Remote views don't let you take advantage of stored procedures, a bit limitation in my book.

What if somebody asked you to take all or part of your application to the web. You data access/update logic is not contained in class defintions that could be migrated to COM components that could intregate with HTML/ASP.

If you need to change some aspect of your business rules, or if the underlying schema changes, you need to recompile your whole application.

You have tied your implementation to VFP. I am sure you have acquired some skills in C/S development. However, because those skills are tied to a VFP implementation, which don't translate that well to other environments, at least as data access is concerned - (nobody else uses DBF's or has the notion of VFP's implementation of remote views). For every 1 VFP client server project, there are 100 or so VB C/S Projects. VB is one of the accepted tools in that market place. Mention VFP in a lot of environments, and you will raise eyebrows.

Here is the acid test for one's committment to VFP. Somebody offers you a $200,000 contract do develop a C/S app using VB. You are:

1. Going to refuse because you use VFP and feel VB is an inferior tool.
2. Going to smash your head into the wall because you lost a great opportunity.

Remote views don't scale. And, having a skill set centered only on VFP would not make my bank account scale either.. I have gone into a lot of technical justification here, I am sure I could find a lot more, but this will suffice. Intrestingly enough, nobody is really arguing the merits of my argument here...I think most folks are just pissed that I am so vocal about my ringing endorsement of VB as a credible C/S tool that compares favorably to VFP.

Folks need to distinguish between what the pesonally feel is a better tool, and what the world perceives as a better tool. There can't be too much wrong VB, since there are a lot of successful projects out there. Sure there are some failed ones as well. Any language can lay claim to that...

Here is another test:

Two developers go to a company. There is the need for a new C/S app there. One is a VB developer. One is a VFP developer. Assuming that 1 of them will get the job, and all other things being equal, who is more likely to get it.

I'll lay 5 to 1 odds the VB guy wins... He can throw darts at all the press clippings that shore up his position. What does the VFP developer have? Besides his feeling that VFP is a better tool, not much else. Oh sure, there are some case studies, whitepapers, etc. However, unless you are already within our community, chances are, you know nothing of these resources. It is a matter of validation. VB has been validated by the world at large as a scaleable, Client/Server development platform, and has been embraced as such. VFP on the other hand is not. Once again, it is not enough for you to believe it, or for MS to say what it is. Rather, it must be validated by the world at large and accepted as such. There is too much empirical evidence to not come to this conclusion...

However, that is not to say that you cannot write scaleable C/S apps in VFP. Check out http://www.mainlinesoftware.com/dataclas2000 for more details.