Hi Jeff...

I love questions like this. Mostly because I like to read the responses. On this forum, you are almost guaranteed to get answers that pump of some non-relevant features of VFP to beat-down VB. Clearly, the VFP developer is the most paranoid programming animial alive.

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.

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

OK, now I will get off the soapbox...

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.

Score VB 1 VFP 0

When comparing UI's, most folks like to tout VFP's inheritance model. And, I was run of the biggest drum beaters around for this. Fact is, while many folks talk about VFP's OO features, most apps don't really subscribe to good OO principles anyway. I know that sounds harsh, but it is the truth. I tend to be much more practical about these things. OO is as much a religion as it is anything else.

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.

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.

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.

In terms of scaleability, C/S apps are much better served by the use of stored procs. This is incompatable with remote views. In this case, you are much better served by the use of of either SQL PassThough, which is suppoted by VFP, or ADO, specifically, the ADO Command Object, which is also supported by VFP. The implementations in VB however, are better. The real advantage of VFP is the ability to express data as a set of local cursors. VFP's langauage is geared toward this environment.

You can see how hard a question this is to answer. There are trade-offs all of the place.

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.

To sum up, I see it breaking down like this:

If you feel comfortable with SQL Passthrough and you really like VFP's UI Designer, and you are not relying on components, VFP will work just fine. ADO will also work fine here as well...

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

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.

It is a matter of thinking outside the box....