John,

Allow me the opportunity to argue with you a bit here. Not that I need your permission, I'd argue with you even if you said no :-)

>As somebody who not only uses both tools extesively, but also uses SQL Server extensively, let me try to be the first person to actually answer your question without telling you that native VFP data is better and that VFP's OO capabilities kick VB's ass, and that VFP has a local data engine that will beat the crap out of SQL. Fact is, none of that is relevant.

I would disagree that VFP's native data handling is irrelevant. Most data manipulation done in an application is not in record based operations but in set based operations. Getting C/S data into a VFP cursor and then using VFP's native DML is far superior to VB's data handling capabilities.

>Most VFP folk have yet to cope with this non-refutable fact....

Oops, if I had known it was non-refutable I wouldn't have refuted it.

>In terms of pure data access, out of the box, VB is better equipped to work with SQL-Server than Visual FoxPro. The VB environment integrates much more seamlessly with ADO than VFP. For starters, VB has the ability to bind to COM events. And, when working with ADO, this is a must.

Again, I have to disagree. While you are right that VB is better with ADO, ADO is not the end of the world. VFP is quite good at getting data from a C/S backend into a VFP cursor. Once the data is in a VFP cursor, there is no rival to munging that data for VFP.

>Score VB 1 VFP 0

My score VFP 1 VB 1

>The fact is , VFP's containership model is what really gives VFP the edge. Most UI's should not go below 1 or 2 layers of inheritance anyway. Most stuff is accomplished through aggregation anyway, or what many folks call composite classes. VB has a control called a usercontrol, that works like VFP's control class.

So, let's see; VFP has containership, VFP has inheritence, VFP has polymorphism, VFP has aggregation, and VFP has composition. VB has composition, VB has aggregation, and VB has polymorphism.

My score VFP 6 VB 4

>VFP's language is richer than the VB langauge. Then again, where the two differ most relates to VFP's local data manipulation language constructs, which is pretty much irrelevant with C/S computing. Of course, when you need it, it is nice to have.


Again, one must do something with the data after it is fetched, that is unless one is writing read only database systems. Once the data is in the VFP cursor, forget VB in the data munging contest.

>Most folks place a lot of faith in VFP's remote views. Remote views are riddled with problems. First off, they are VFP specific. Second, they represent an incomplete wrapper around ODBC. Finally, they do not fit into a multi-tier/COM-Based environment. So, if you do elect to use VFP, your best bet is going to center around writing your classes that will encapsulate your data access requirements and bypass remote views all together.

Remote views are not the only way to get data from a backend into a VFP cursor (as I know you are aware). SQL PT is not rocket science either.

>If you plan to use middle tier COM Components, VB has the edge here. Once again, VB COM Components can both raise and respond to events. Yes, VFP has VFPCOM.DLL, and it does appear to work, but it only responds to events, events cannot be raised. And, when talking about looslely coupled components, events are at the heart of it all. This is the basis for all the new COM + stuff. Once again, you can make a lot of stuff work with VFP. However, you need to decide if you are going to be engaged in the process of making stuff work, or working in an environment that truly supports what you are attempting to do.

Your win this one about teh events. Although, with stateless COM servers I don't necessarily see raising and responding to events as particularly critical to implementing a middle tier component.

>If you need to work with multiple components, VB has the advantage hands down.

Hands down for what part of the system? VB can't compete with VFP for data munging. VB has some advantages for middle tier, but not enough to "bury" VFP on that tier, and VB has no abilities in directly handling data by itself.

>So, it is a fairly limited set of circumstances where VFP has a real-advantage over VB. And, to say VFP has any real-advantage is quite a stretch.

I really disagree with this statement. VFP is clearly better at munging data than VB. VFP has a clearly superior development model (OOP RDBMS) than VB. Truthfully, VB has advantages and so does VFP, but finding VFP the tool of choice is no stretch.